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ABSTRACT 


This  thesis  describes  the  detailed  design  of  a 
distributed  operating  system  for  a  real-time,  microcomputer 
based  multiprocessor  system. 

Process  structuring  and  segmented  address  spaces 
comprise  the  central  concepts  around  which  this  system  is 
built.  The  system  particularly  supports  applications  where 
processing  is  partitioned  into  a  set  of  multiple  processes. 
One  such  area  is  that  of  digital  signal  processing  for  which 
this  system  has  been  specifically  developed. 

The  operating  system  is  hierarchically  structured  to 
logically  distribute  its  functions  in  each  process.  This  and 
loop-free  properties  of  the  design  allow  for  the  physical 
distribution  of  system  code  and  data  amongst  the 
microcomputers.  In  a  multiprocessor  configuration,  this 
physical  distribution  minimizes  system  bus  contention  and 
lays  the  foundation  for  dynamic  reconfiguration. 
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I.  INTRODUCTION 


A.  DISCUSSION 

The  topic  of  this  thesis  is  the  detailed  design  of  the 
kernel  of  a  real-time  microcomputer  based  multiprocessor 
operating  system.  The  kernel  comprises  a  complete,  albeit 
primitive,  operating  system  providing  support  for  a  large 
number  of  asynchronous  processes. 

The  kernel  manages  all  physical  processor  resources 
thereby  providing  the  user  with  an  execution  environment 
relatively  free  from  concern  about  the  underlying  hardware 
configuration.  The  system  is  capable  of  p°rforming  in  a 
real-time  environment  through  the  use  of  preemptive 
scheduling  to  ensure  expeditious  handling  of  time-critical 
processing  requirements. 

Despite  the  rapidly  expanding  capabilities  of  modern 
microcomputer  systems,  they  still  prove  to  be  limited  by  the 
relatively  slow  execution  speeds  of  their  microprocessors. 
These  systems  generally  do  not  provide  the  pcwer  and 
flexibility  required  to  address  complex  and  demanding 
applications.  One  such  area  is  that  of  real-time  digital 
image  processing.  This  is  a  particularly  demanding 
application  area  characterized  by  the  requirement  to  apply 
significant  processing  power  to  a  high  input  data  rate. 
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A  natural  answer  to  the  inadequacies  of  the  lone 
microcomputer  is  to  provide  for  multiple  microcomputer 
systems.  Such  systems  could  provide  the  processing  power  to 
adequately  handle  applications  which  are  presently  addressed 
only  within  the  domain  of  minicomputers  and  mainframe 
systems.  However,  the  general  purpose  microcomputer 
operating  system  which  would  control  such  a  system  does  not 
exist  today.  Host  of  today's  microcomputer  operating  systems 
deal  only  with  uniprocessors  and,  in  fact,  could  net 
adequately  manage  multiple  processors. 

The  integration  of  large  numbers  of  relatively 
inexpensive  microcomputers  into  powerful  computer  systems 
has  teen  the  subject  of  intensive  research  in  universities 
and  industry  for  several  years.  As  a  result,  a  number  of 
multiple  microcomputer  systems  such  as  Carnegie-Hellon's  Cm* 
[16]  have  been  built  and  even  mere  such  as  the  varied 
architectures  of  Anderson  and  Jensen  [l]  have  been 
sum^ested.  The  Cm*  is  an  ambitious  system  with  5?  processors 
and  a  complex,  custom  designed  and  built  bus  structure  [IS]. 
Host  of  the  proposed  systems  require  this  type  of 
specialized  hardware.  The  primary  thrust  of  this  thesis  is 
towards  a  general  control  structure  which  can  be  applied  to 
hardware  systems  that  are  commercially  available  today  with 
only  very  minor  or  no  hardware  development.  Thus  no  serious 
attempt  is  made  to  consider  alternative  hardware 
architectures  as  a  topic  in  this  research. 
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A  complete  high  level  operating  system  design  was 
provided  by  O'Connell  and  Richardson  [11]  in  their  family  of 
secure  multiprocessor  operating  systems.  This  thesis 
concerns  itself  with  the  detailing  of  one  member  of  their 
family,  a  modified  real-time  subset.  The  modification 
consists  of  the  Inclusion  of  a  more  general  synchronization 
mechanism,  eventcounts  and  sequencers  described  by  Reed  and 
Kanodia  [13]  which  replace  the  more  traditional  Signal/Wait 
and  Block/Wakeup  used  in  the  original  design. 

The  system  supports  multiple  asynchronous  processes 
using  the  concept  of  two-level  traffic  control  to  accomplish 
processor  multiplexing  amongst  a  greater  number  of  eligible 
processes.  This  dual-level  processor  multiplexing  design 
allows  the  system  to  treat  the  two  primary  scheduling 
decisions,  viz.,  the  scheduling  of  processes  and  the 
management  of  processors  at  two  separate  levels  of 
abstraction. 

B.  STRUCTURE  OF  THE  THESIS 

Chapter  II  describes  the  overall  design  philosophy  cf 
the  operating  system,  how  multiple  processes  are 
synchronized  and  how  their  multiplexing  on  a  smaller  set  of 
processors  is  accomplished.  Chapter  3  describes  the  hardware 
architecture  of  the  multiprocessor  system  in  terms  of  the 
particular  hardware  suite  chosen  for  this  system.  Chapter  IV 
discusses  the  details  of  the  kernel  design.  The  final 


chapter  presents  conclusions  and  observations  that  resulted 
from  this  effort  and  suggestions  for  further  research.  Two 
appendices  are  also  provided,  an  explanation  of  programming 
methodology  for  this  system  and  a  detailed  description  of 
the  kernel  modules  in  their  present  form. 
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II.  FUNDAMENTAL  DESIGN  CONCEFTS 


A.  DESIGN  PHILOSOPHY 

Multiple  processor  systems  are  intrinsically  more 
complex  then  the  familiar  uniprocessor.  Their  complexity  has 
proven  to  he  the  major  harrier  to  realizing  the  full 
potential  of  the  inherent  parallelism  available  in  such  a 
system. 

One  of  the  most  important  components  of  any  computer 
system  is  the  operating  system.  The  operating  system  manages 
the  system's  resources.  Thus  system  performance  is 
critically  dependent  upon  its  effectiveness.  However, 
performance  is  not  Just  raw  computational  speed,  hut  is  in 
reality  the  sum-total  of  numerous  attributes.  Some  of  these 
system  attributes  such  as  ease  of  programming,  correct 
operation,  and  the  ability  to  address  diverse  applications 
are  as  important  as  speed  and  efficiency,  but  too  often  are 
overlooked.  Pecause  of  this  potentially  very  large  set  of 
requirements,  adequate  performance  can  only  be  assured  if 
the  behavior  of  the  system  is  well  understood  by  the 
designer.  Of  necessity,  this  imposes  a  strict  requirement 
for  simplicity. 

In  this  design,  the  requirement  for  simplicity  is 
satisfied  by  utilizing  a  model  based  on  the  notion  of 
multiple  asynchronous  processes  wit.n  segmented  address 
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spaces.  This  is  the  central  unifying  concept  which  provides 
a  straightforward  view  of  both  static  and  dynarric  system 
behavior  [4].  The  principles  of  structured  system  design  are 
also  applied  to  logically  organize  the  operating  system  into 
a  hierarchically  structured  set  of  easily  understood  modules 
whose  interactions  are  clearly  specified  and  strictly 
enforced . 

1 

The  result  is  a  modular,  layered  operating  sytem  which 
is  both  smaller  and  easier  to  analyze.  This,  in  turn  makes 
it  easier  to  ensure  correct  operation  and  provides  better 
opportunity  for  improving  performance  through  tuning. 
Certain  other  benefits  accrue  from  simplificaton  as  well. 
Because  the  sytem  is  smaller,  less  memory  is  used  for 
operating  system  code  and  less  processor  time  is  spent  in 
its  execution. 

I.  SEQUENTIAL  PROCESSES 

1 .  Definition  of  a  Process 

The  concept  of  a  process  has  proven  to  be  a 
fundamental  and  powerful  one  in  the  organization  cf  computer 
systems.  The  rather  abstract  idea  of  a  process  has  been 
defined  in  numerous  ways,  but  perhaps  the  simplest  is 
offered  by  J.  Saltzer  as: 

"...basically  a  program  in  execution  on  a  processor."  fl7] 
In  considering  the  above  definition,  it  becomes 
apparent  that  there  are  two  elements  which  together 
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completely  characterize  a  given  process.  They  are  1)  the 
program,  consisting  of  any  sequentially  executed  machine 
instructions  and  data  which  can  he  associated  with  the 
program  (usually  termed  the  process'  address  spare)  and,  2) 
the  execution  state  of  the  process  which  is  characterized  ty 
the  contents  of  certain  processor  registers. 

2.  The  Process  Address  Space 

The  address  space,  simplistically,  provides  for  the 
encapsulation  of  a  process  such  that  it  has  no  knowledge  of 
any  other  process  and  no  other  process  has  knowledge  of  it. 
This  eliminates  the  possibility  of  inter-process 
interference  simply  because  processes  are  unahle  to  "escape” 
the  confines  of  their  defined  address  spaces. 

However,  this  is  rather  restrictive  in  that 
processes  which  are  totally  ignorant  of  each  other  have  no 
hope  of  co-operating  towards  the  accomplishment  of  some 
greater  goal.  In  order  to  mediate  this  constraint,  one 
desires  tc  allow  some  restricted  (controlled)  form  of 
address  space  overlap  (viz.,  sharing)  such  that  co-operation 
is  allowed  while  still  retaining  the  benefits  of  protection 
offered  by  isolation.  Snaring  requires  some  way  cf 
distinguishing  the  shared  portions  of  the  address  space. 
This  is  greatly  facilitated  by  introducing  the  ncticr.  o'* 
memory  segmentation. 


a.  Virtual  Memory  and  Segmentation 

Virtual  memory  is  used  to  implement  the  concept 
of  a  per  process  address  space.  In  Multics  [2],  each  process 
is  provided  with  its  own  virtual  memory  for  an  address 
space.  These  virtual  memories  are  completely  independent  of 
one  another. 

A  virtual  memory  consists  of  a  set  of  segments. 
Segments  are  distinct  variable  size  memory  objects  which 
contain  information.  Associated  with  a  segment  is  a  set  of 
logical  attributes  used  to  uniquely  identify  the  segment  and 
to  control  access  to  it. 

In  specifying  the  set  of  segments  that  comprise 

a  virtual  memory,  one  may  include  segments  that  are  part  of 

other  virtual  memories  as  well.  Thus  segments  can  be  shared 

in  a  controlled  manner  to  provide  for  inter-process 
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communicat ion  and  co-operation. 

By  using  segmentation  to  provide  a  virtual 
memory  environment,  the  user  is  presented  with  a 
configuration  independent  system  in  that  he  "sees’’  a  process 
address  space  that  he  can  consider  his  own  and  is  not 
dependent  on  the  assignment  of  physical  addresses. 

b.  Addressing  in  a  Segmented  System 

Addressing  in  a  segmented  memory  system  is 
two-dimensional.  That  is,  a  complete  address  consists  of  two 
parts.  The  first  is  the  segment  number.  This  identifies  the 
particular  segment  of  interest.  One  attribute  of  the  segment 


is  the  physical  address  of 

the  segment 

's  base. 

Thus 

the 

segment 

can 

be  located 

anywhere  in 

physical 

memory  by 

changing 

the 

base  address 

.  The  second 

dimersi on 

of 

the 

address 

is 

an  offset  relative  to  the 

segment 's 

base 

( the 

beginning 

of 

the  segment). 

This  serves 

to  access 

spec 

if  ic 

locations  within  the  segment. 

C.  INT2R-PR0CESS  SYNCHRONIZATION  ANT  COMMUNICATION 

Utilizing  the  parallelism  afforded  by  multiple 
processors  requires  a  mechanism  for  in ter-proress 
communication  and  synchronization.  It  is  used  for 
controlling  the  execution  of  processes  and  coordinating  the 
sharing  of  data. 

The  most  widely  used  synckrcniza tion  primitives  are 
Dijkstra's  semaphores  [3]  or  Saltzer's  Block  and  Vakeup  fi?] 
which  were  used  in  O'Connell  and  Richardson's  original 
design  Til]  .  However,  the  design  decision  was  made  to  use  a 
different  mechanism  which  addresses  the  questions  of 
confinement  in  a  secure  system.  This  is  the  synchrorizat ion 
mechanism  based  on  the  eventcounts  and  sequencers  of  r.eed 
and  Kanod ia  [13]  . 
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D.  PROCiSSOs  MTJITIPI2XING 


1 .  Tefinition  of  Processor  Multiplexing 

Processor  mul t iplexing  is  a  technique  for  sharing 
scarce  processor  resources  among  an  arbitrarily  large  number 
of  processes.  It  is  accomplished  by  simulating  the  existence 
of  a  larger  number  of  virtual  processors.  This  technique  is 
widely  used  in  conventional  uniprocessor  systems  where  it  is 
commonly  called  multiprogramming.  It  seeks  to  maximize  the 
use  of  the  available  hardware  by  automating  control  of 
process  loading  and  execution.  It  also  greatly  increases  the 
flexibility  of  a  system  allowing  it  to  be  effective  in  more 
complex  and  demanding  applications. 

J.  H.  Saltzer  [17]  presented  one  of  the  fundamental 
works  on  the  subject  of  processor  multiplexing.  His  thesis 
provides  an  excellent  treatise  of  the  salient  issues. 

2.  processor  Virtualization 

In  order  to  effect  processor  multiplexing,  the 
physical  processor  resources  Uhose  hardware  devices  that 
execute  maccine  instructions)  are  virtualized  by  creating 
abstract  processors  called  virtual  processors. 

a.  Virtual  Processors 

Rach  physical  processor  posseses  some  internal 
memory  (registers)  whose  contents  describe  the  processor's 
state.  As  part  of  the  processor  state,  there  is  a 
specification  of  the  accessible  address  space  which  contains 
the  instructions  and  data  used  by  the  processor. 

2C 


Virtual  processors  are  simulations  of 
processors.  They  can  he  viewed  in  essentially  the  same  way 


as  physical 

processors 

in 

that  they 

execute 

the  same 

instructions . 

However, 

the 

instruction 

se  t  cf 

a  virtual 

processor  has  been  expanded  to  include  some  instructions 
which  the  physical  processors  do  not  directly  have.  These 
include  "instructions”  to  "load"  a  process,  certain 
synchronicat ion  primitives,  system  service  calls,  etc. 

Virtual  processors  exist  only  as  abstract 
processors  represented  by  a  data  structure.  They  are  used  as 
the  vehicle  for  the  control  and  manipulation  of  processor 
resources . 

3 .  Two-level  processor  Multiplexing 

In  this  design,  there  are  two  levels  of  processor 
multiplexing.  This  design  arose  from  the  existence  of 
multiple  physical  processors.  Each  of  the  levels  address  a 
distinct  requirement.  One  level  supports  virtual  processor 
management,  that  is,  the  prevision  of  inter-process 
synchronization.  The  other  supports  the  management  of 
physical  resources  by  the  operating  system. 

This  divides  the  requirements  for  multiplexing 
mechanisms  into  two  parts.  One  of  these  addresses 
multiplexing  virtual  processors  among  processes  and  the 
other  multiplexing  physical  processors  amon*?  virtual 
processors . 
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a.  The  Traffic  Controller 


The  Traffic  Controller  represents  the  upper  level 
of  processor  multiplexing  (termed  level  2)  and  provides  the 
mechanism  for  multiplexing  virtual  processors  among 
processes.  Thus  it  is  responsible  for  inter-process 
synchronization. 

As  an  example,  consider  that  a  process,  called  A, 
will  wish  to  synchronize  its  actions  with  another  process, 
called  B,  such  that  process  B  will  have  to  complete  some 
task  before  A  can  continue  execution.  Thus  A  will  execute  to 
the  point  where  it  cannot  proceed  further  and  wishes  to 
signal  process  B.  When  process  B  has  finished  its  task,  it 
must  notify  process  A  of  its  completion  so  that  process  A 
may  then  proceed. 

This  inter-process  synchronization  is  handled  at 
the  level  of  the  Traffic  Controller.  When  process  A 
discovered  that  it  could  not  proceed  further,  it  "gave  away” 
its  virtual  processor  to  some  process  that  could  run.  The 
Traffic  Controller  suspended  the  execution  of  process  A  and 
a  new  process  was  bound  to  the  virtual  processor.  In  the 
same  way,  when  B  completes,  viz.,  it  has  no  more  work  to 
perform,  it  will  also  give  its  virtual  processor  away. 

b.  The  Inner  Traffic  Controller 

The  Inner  Traffic  Controller  comprises  the 
lower  level  of  processor  multiplexing  (level  1)  and  provides 
the  second  set  of  multiplexing  functions.  It  multiplexes  the 


physical  processor  among  one  or  irore  virtual  processors. 
While  the  virtual  processors  have  identical  capabilities, 
the  physical  processors  may  differ  in  their  capabilities , 
viz.,  they  may  have  different  attached  I/C  devices, 
different  local  memory  sizes,  etc.  The  Inner  Traffic 
Controller  must  manage  the  physical  resources  ir.  such  a  way 
that  the  user  is  unaware  of  these  differences.  In 
particular,  the  system's  interrupt  system  is  managed  by  the 
Inner  Traffic  Controller. 

If  a  user  process  calls  upon  some  system  service, 
such  as  disk  I/O  or  I/O  for  a  real-time  sensor,  it  must  wait 
for  that  service  to  be  completed  before  it  can  proceed.  The 
performance  of  a  system  service  is  considered  to  be  part  cf 
the  requesting  processes.  However,  it  may  actually  be 
supported  by  another  virtual  processor.  To  control  this 
interaction  the  Inner  Traffic  Controller  nrcvides  the 
required  inter-virtual  processor  synchronization  mechanism. 
In  particular,  a  physical  system  interrupt  is  directly 
transformed  into  a  synchronization  signal  to  a  waiting 
virtual  processor.  This  structure  is  particularly  important 
for  the  support  of  real-time  processing. 

4.  Processor  Multiplexing  Strategy 
a.  Process  State  Transitions 

Figure  1  illustrates  the  state  transitions  of  a 
set  of  processes  as  a  virtual  processor  is  multiplexed  among 
them.  Some  eligible  process  (one  which  is  in  the  ready 
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state)  is  scheduled  to  run  and  is  bound  to  the  virtual 
processor.  At  this  time,  the  process  makes  the  transition  to 
the  running  state.  As  far  as  the  process  is  concerned,  once 
it  enters  the  running  state,  it  is  executing. 

At  some  point  in  its  execution,  the  process  may- 
desire  to  block  itself  or  signal  another  process.  If  it 
blocks  itself  (enters  tne  blocked  state),  it  will  give  up 
the  virtual  processor  to  which  it  is  presently  bound  and 
will  be  out  of  contention  for  processor  resources.  It  will 
remain  in  the  blocked  state  until  some  other  process  signals 
it  (thus  making  the  transition  back  to  the  ready  state).  If 
the  process  signals  other  processes,  it  will  transition  from 
the  running  state  back  to  the  ready  state  from  which  it  may 
be  scheduled  to  run  again.  In  doing  so.  it  allows  the 
Traffic  Controller  to  possibly  give  the  virtual  processor  to 
some  higher  priority  process  which  may  be  ready  to  run. 
b.  Virtual  Frocessor  State  Transitions 

Figure  2  illustrates  the  state  transitions  made 
by  virtual  processors  as  a  physical  processor  is 
multiplexed.  This  diagram  is  very  similar  to  that  of  Figure 
1.  However,  these  transitions  are  not  directly  observeable 
by  processes  (except  as  differences  in  execution  times)  as 
virtual  processor  state  transitions  result  from  the 
management  of  physical  resources  by  the  operating  system. 

In  Figure  2,  it  can  be  seen  that  a  running 
virtual  processor  can  transition  to  the  waiting  state  or  the 


ready  state.  The  transition  to  the  waiting  state  occurs  when 
a  virtual  processor  must  wait  for  completion  of  some  system 
service  {analogous  to  the  blocking  of  process  A  in  the 
example  siven  in  paragraph  a).  While  in  the  waiting  state, 
the  virtual  processor  is  out  of  contention  for  processor 
resources  until  another  virtual  processor  signals  it  to 
continue.  While  in  the  ready  state,  the  virtual  processor  is 
in  contention  for  processor  resources  and  so  may  be 
scheduled  to  run  on  the  physical  processor. 
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III.  MULTIPROCESSOR  ARCHITECTURE 


A.  HARDWARE  REQUIREMENTS 

One  of  the  principal  design  goals  of  the  system  design 
was  to  provide  for  configuration  independence.  Therefore, 
the  operating  system  imposes  hut  a  few  constraints  on  the 
hardware  that  are  noted  here. 

1 .  Shared  Global  Memory 

rphe  operating  system  maintains  system-wide  control 
data  accessible  to  each  of  the  processors  via  shared 
segments.  The  communication  path  utilized  for  sharing  this 
data  is  shared  memory.  Thus  some  shared  memory  must  he  made 
available  to  each  microcomputer  in  such  a  way  as  to  allow 
independent  access  at  the  level  of  single  memory  references. 

2 . '  Multiprocessor  Synchronization  Support 

There  must  exist  some  hardware-supported 
multiprocessor  synchronization  primitive.  This  can  he  any 
form  of  an  indivisible  read-alter-rewrite  memory  reference. 
This  capability  is  required  to  implement  global  locks  on 
shared  data  to  prevent  race  conditions  as  the  physical 
processors  attempt  to  asynchronously  manipulate  shared  data. 

3 .  Inter-Processor  Comminlcat  Ion 

Some  method  of  communication  between  physical 
processors  must  be  provided.  This  is  satisfied  by  an  ability 
to  generate  interrupts  between  the  physical  processors.  This 
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capability  is  required  for  the  implementa tion  of  preemptive 
scheduling. 


B.  HAREVARE  CONFIGURATION 

1 .  System  Configuration 

The  hardware  sub-system  is  configured  as  a 
multiprocessor  [l] .  The  system  consists  of  a  number  of 
single  board  microcomputers  and  a  global  memory  module 
connected  by  a  single  snared  bus.  The  system  differs  from 
conventional  multiprocessors  in  that  each  of  the 
microcomputers  possesses  its  own  local  memory.  Tbe  global 
memory  module  is  connected  directly  to  the  system  bus  and  is 
the  only  physical  memory  resource  which  is  shared  by  all  of 
the  processors.  The  general  configuration  is  shown 
schematically  in  Figure  3. 

2 .  Specific  Hardware  Employed 

The  particular  hardware  selected  for  this 
implementation  is  based  on  the  INTEL  S6/12A  single  board 
microcomputer  [6],  This  microcomputer  utilizes  the  INTEL 
5056,  a  16-bit  general-purpose  microprocessor  capable  of 
directly  addressing  a  total  of  1  mega-byte  of  physical 
memo  ry . 

a.  The  5056  Microprocessor 

The  £C£6  does  not  support  the  notion  of  explicit 
segmentation.  In  the  5055,  addressing  is  segment-like  ir. 
that  base  and  offset  addressing  is  used.  The  offsets  are 
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forced  relative  to  ore  of  the  four  segment  base  registers  of 
the  3096:  1)  the  Code  Segment  Register,  used  for  addressing 
a  pure  segment  containing  executable  code,  2)  the  lata 
Segment  Register,  used  for  process  local  data,  3)  the  Stack 
Segment  Register,  used  for  the  per  process  stacks,  and  4) 
and  the  Rxtra  Segment  Register,  typically  used  for  external 
or  shared  data. 

In  the  c££6,  a  segment  can  range  anywhere  up  to 
64  kilo-bytes  in  length.  Segments  can  be  placed  anywhere 
within  the  1  mega-byte  address  space  of  the  £C£6  as  long  as 
the  segment  base  is  placed  on  an  even  hexadecimal  memory 
address.  Segment  access  and  bounds  checking  are  not 
supported.  Although  there  is  no  general  segmentation 
hardware,  this  design  effects  a  segmented  address  space 
through  a  combination  of  operating  system  support  and  system 
initialization  conventions  described  in  a  companion  thesis 
by  Ross  [16]  . 

b.  The  86/12A  Single  Board  Microcomputer 

The  36/12A  is  a  complete  computer  capable  of 
stand-alone  operation  used  as  the  basic  processing  ncde  of 
the  multiprocessor.  It  is  a  commercial  product  which 
satisfies  the  three  basic  hardware  requirements  for  this 
operating  system.  First,  possessing  a  system  bus  interface, 
ea<"h  microcomputer  is  capable  of  independently  accessing  a 
global  shared  memory  via  the  system  bus.  Secondly,  the  6036 
CPU  supports  multiprocessor  synchroniza ton  directly  with  an 


29 


indivisible  test-and-set  semaphore  instruction  performed 
under  bus  lock.  lock  semaphores  reside  in  the  shared  global 
memory  si*ce  the  system  bus  must  be  locked  to  ensure  tnat 
this  instruction  operates  correctly.  Thirdly,  preempt 
interrupts  can  be  generated  by  using  the  parallel  I/O  ports 
provided  on  each  microcomputer.  This  requires  connecting  the 
microcomputer 's  parallel  I/O  ports  to  the  system  interrupt 
structure. 

c.  Preempt  Interrupt  Hardware  Connection 

As  with  most  mi  coprocessors ,  the  3CS  €  itself 
does  not  possess  the  capability  to  directly  generate 
interrupts  destined  for  other  devices  (the  devices  of 
interest  here  are  other  processors^.  The  system  interrupt 
lines  are  accessible  through  a  Jumper  matrix  [5]  located  on 
the  microcomputers.  The  parallel  I/C  port  output  of  each 
I  SBC  85/12A  Is  connected  to  this  interrupt  Jumper  matrix. 
Preempt  interrupts  ere  then  generated  simply  by  outputting  a 
single  word  through  the  parallel  port  onto  the  system 
interrupt  lines.  The  connection  is  shown  in  Figure  4. 

Note  that  only  a  single  interrupt  line  is 
actually  required  to  implement  system-wide  preempt 
interrupts.  In  this  implementation,  four  lines  are  used. 
This  provides  four  unique  interrupt  lines.  If  more  than  four 
processors  are  used  in  the  system,  then  these  lines  are 
multiplexed  (viz.,  several  processors  share  an  interrupt 
line) . 
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d.  The  System  Bus 

The  Intel  MUITI3US  [6]  is  utilized  as  the  system 
bus.  It  is  a  widely  used  commercial  product  with  a  published 
set  of  standards.  This  bus  is  specifically  designed  to 
support  multiple  processors  and  is  fully  compatible  with  the 
microcomputers  used.  It  is  utilized  without  modification. 

C.  HAS  TV  ARE  ASSESSMENT 

The  commercially  available  66/12A  single  board 
microcomputer  was  chosen  because  it  was  specifically 
designed  to  provide  support  for  multiple  processor  systems. 
In  using  the  operating  systen  described  in  the  nett  chapter 
to  manage  the  microcomputer's  physical  resources,  this 
microcomputer  is  entirely  suitable  for  use  as  a  basic 
processing  node  of  an  effective  multiprocessor  system. 
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IV.  DETAILED  SIFTED  DESIGN 

A.  STRUCTURE  07  TEE  OPERATING  SYSTEM 

This  operating  system  provides  a  mul ti programmed 
multiprocessor  system  with  segmented  process  address  spaces 
using  the  hardware  described  in  Chapter  III.  The  operating 
system  is  structured  as  a  hierarchy  of  three  levels  [11],  as 
follows : 

level  3:  Supervisor 

level  2:  Traffic  Controller 

level  1:  Inner  Traffic  Controller 

The  Inner  Traffic  Controller  (level  1)  forms  the 
bottom  level  of  the  hierarchy.  It  is  "closest”  to  the 
hardware  and  encompasses  the  major  machine-dependent  aspects 
of  the  system.  The  Inner  Traffic  Controller  multiplexes  the 
physical  processor  amongst  a  pool  of  more  numerous  virtual 
processors . 

Residing  at  the  nert  level  (level  2)  is  the  Traffic 
Controller,  which  is  responsible  for  multiplexing  virtual 
processors  among  a  larger  number  of  user  processes  competing 
for  resources.  The  user-accessible  inter-process 
communication  and  synchronization  primitives  (Advanc®,  Await 
and  Ticket^  provided  at  this  level  allow  the  user  to  easily 
address  complex  system-wide  inter-process  synchronization 
requi rements . 


34 


The  Supervisor  resides  at  the  topmost  level  (level 
3).  The  Supervisor's  purpose  is  to  provide  common  services 
for  user  processes.  In  this  implementation,  it  only  provides 
a  simple  higher  order  language  interface  to  the  kernel  by 
having  a  single  entry  point  into  the  kernel. 

5.  TISTP IB'JT IMG  TK"  OPSp.ATING  SYSTEM 

One  cf  the  primary  concerns  in  any  multiple  computer 
system  is  the  issue  of  performance.  In  this  type  of  system, 
a  multiprocessor  with  a  single  shared  system  bus,  the  most 
glaring  potential  bottleneck  is  the  system  bus.  It  then 
becomes  highly  desirable  to  minimize  accesses  to  this 
resource  that  must  be  shared  by  all  of  the  microcomputers. 

In  terms  of  the  design,  the  described  system  is  a 
distributed  operating  system  patterned  after  Unities  [12], 
In  particular,  the  segments  of  the  operating  system  kernel 
are  distributed  as  part  of  the  address  spare  of  each 
process.  In  terms  cf  the  implementation  of  this  system,  the 
performance  issue  is  addressed  by  physically  distributing 
copies  of  the  kernel  in  the  local  memories  of  each  cf  the 
microcomputers.  This  allows  high-speed  access  to  kernel 
functiors  without  reces si ta t i ng  use  of  the  system  bus  for 
code  fetches. 

Thus  each  computing  node  can  be  regarded  as 
semi-autonomous  in  that  each  of  the  processors  schedule 
themselves  but  are  still  centrally  controlled  by  the  set  of 
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system-wide  data  tables.  There  is  no  concept  of  a 
master-slave  relationship  among  individual  microcomputers, 
nor  are  individual  kernel  functions  divided  up  among  them  as 
is  more  often  done.  Rather  the  entire  kernel  is  distributee. 

C.  REAL-TIME  PROCESSING 

Real-time  processing  involves  the  performance  of 
time-cri tical  processing  often  related  to  the  control  of 
external  devices.  This  application  requires  that  seme 
mechanism  he  employed  to  ensure  that  time-cri tical 
processing  is  given  immediate  attention. 

The  hardware-supported  process  preemptin’'  mechanism 
employed  in  the  system  provides  th»  rapid  response  required 
for  real-time  processing.  The  priority-driven  preemptive 
scheduling  technique  used  provides  for  expeditious  handling 
of  processes  which  perform  time-critical  functions.  These 
processes  are  assigned  high  priorities  so  that  the  system 
will  preempt  other  processes  of  lower  priority  thdt  ray  he 
running.  Thus  when  or.e  of  these  high-priori  ty  processes  is 
signalled,  it  can  he  immediately  scheduled  and  main  control 
of  processor  resources. 

D.  PROCESS  ADDRESS  SPACES 

The  address  space  of  a  process  is  a  set  of  PI/v-&6 
segments:  procedures  (code),  local  variables  (data'. 


external  lata  (shared  data),  and  stack  [12,12].  Physical 
memory  is  allocated  to  the  segments  of  a  process  i  r.  such  a 
way  as  to  limit  system  bus  contention,  as  discussed  t y  F.oss 
[16].  In  this  system,  the  stack  is  a  key  element  in  the 
management  of  processes. 

1 .  The  PI/M-S6  Stack 

Intel's  high  order  language  PL/M-86  T5,  If]  utilizes 
stack  segments  to  implement  per  process  stacks.  Addressing 
of  stacks  is  accomplished  hy  using  three  of  the  8C86's 
registers  as  shown  in  Figure  5.  The  Stack  Segment  (SS) 
Register  contains  the  base  location  of  the  stack  segment  in 
memory.  The  Stack  Pointer  (Sr)  Register  addresses  the 
current  top  of  the  stack  as  ap  offset  from  the  base  of  the 
stack  Segment,  (the  value  in  the  SS  Registers.  The  Ease 
Pointer  (EF)  Register  also  holds  an  offset  from  the  SS 
Reeist°r  and  is  used  to  establish  procedure  activation 
records  [7  ,  8  ,  9] . 

2 .  The  5, tack  as  the  Address  Space  Tescriptor 

In  this  system,  the  per  process  stacks  are  used  to 
maintain  process  state  information.  This  includes  the 
current  execution  point  (when  the  process  is  not  actually 
running),  the  type  of  return  from  the  kernel  rea.uired  for 
the  process  (normal  or  interrupt^  and  the  locations  of  the 
code  and  data  segments.  This  allows  the  syster  to  swap  in  a 
new  address  space  (viz.,  do  a  context  switch)  tv  changing 
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the  value  in  the  SS  Register,  which  is  thus  used  in  a  [fanner 
somewhat  analogous  to  the  Idultics  Descriptor  Base  Register 
[12]  . 

Figure  6  shows  how  this  information  is  stored  in  the 
stack  while  a  process  is  not  actually  running  on  a  physical 
processor.  The  Base  Pointer,  Stack  Pointer  and  Return  Type 
Indicator  are  stored  in  reserved  locations  at  the  very 
beginning  of  the  stack  segment. 

In  order  to  identify  the  stack  segment,  and  thus 
access  the  address  space  of  a  process,  the  stack  segment 
tase  address  is  used  in  a  dual  role.  First,  a  unique  base 
address  is  assigned  to  the  stack  of  each  process  which 
provides  a  unique  segment  for  each  stack.  This  base  address 
is  used  for  addressing  locations  within  the  stack.  Secondly, 
the  base  address  serves  as  a  descriptor  for  the  address 
space  of  each  process.  Thus  the  binding  of  a  processor  is 
changed  from  one  process  to  another  "merely"  by  chanmin?  the 
base  address,  viz.,  changing  the  value  in  the  Stack  Segment 
(SS)  Register. 

E.  SYSTEM  PROCESSES 

System  processes  make  up  the  non-di st riluted  kernel. 
Non-dis tributed  refers  to  the  fact  that  these  processes  are 
not  distributed  as  part  of  each  process'  address  space. 
Rather  they  represent  various  system  services.  System 
processes  are  used  for  the  management  of  hardware  resources 
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and  execute  asynchronously  with  respect  to  user  processes. 
In  this  design,  all  system  processes  are  permanently  hound 
to  dedicated  virtual  processors. 

1 .  The  Idle  Virtual  Processor 

The  idle  virtual  processor  provides  the  physical 
processor  with  a  consistent  state  when  no  other  virtual 
processor  is  ready  to  be  run.  The  idle  virtual  processor 
assures  that  physical  processors  always  have  some  valid 
process  address  space  to  execute  in,  although  in  this  case 
it  is  only  an  idle  process  that  performs  no  useful  work. 

This  is  assumed  by  creating  for  each  physical 
processor  a  dedicated  idle  virtual  processor.  The  idle 
virtual  processors  act  as  "default"  that  will  only  be  run 
when  no  other  runnable  virtual  processors  are  found. 

7.  SYNCHRONIZATION 

Synchronization  is  requi red  at  two  levels  in  this 
system:  between  processes  (at  the  Traffic  Controller  level) 
and  between  virtual  processors  (at  the  Inner  Traffic 
Controller  level).  5oth  levels  use  the  eventcount  and 
sequencer  mechanisms  [13]  described  below. 

1 .  Sven  tcoun  ts 

Sventcounts  are  used  in  this  system  to  allow 
processes  to  arbitrate  access  to  shared  resources. 
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An  eventcourt  is  defined  by  Reed  to  be: 

"an  object  in  the  system  that  represents  a  class  of  events 
that  will  eventually  occur.”  [14] 

Each  eventcount  represents  a  distinct  class  of  events.  An 
eventcount  is  associated  with  seme  type  of  event  of 
interest,  e.g.,  occurrence  of  a  real-time  interrupt,  a 
buffer  becoming  full,  a  data  segpient  being  read  or  written 
into,  etc.  Event  counts  are  implemented  as  sets  of  positive 
integers  from  £  to  infinity  (the  limit  is  actually  65,536 
using  PI/M-S6  "word"  variables  which  is  "adequate"  for  the 
applications  anticipated)  and  are  used  to  keep  track  of  the 
total  number  of  such  events  that  have  occurred. 

Three  operations  are  defined  on  eventcounts.  The 
value  of  an  eventcount  may  be  obtained  by  the  READ 
operation.  This  returns  the  present  value  of  the  eventcount 
as  a  positive  integer  k.  From  this  value,  one  may  infer  that 
events  £  to  k  have  already  occurred. 

The  AWAIT  operation  allows  a  process  to  suspend  its 
own  execution  (enter  the  blocked  state)  until  a  specified 
event  has  occurred,  viz.,  the  eventcount  reaches  the  value 
specified.  The  effect  is  the  same  as  the  conventional  Plock 
operation  or  Dijkstra's  "P"  operator. 

An  ADVANCE  operation  is  performed  by  a  process  when 
an  event  has  occurred.  It  increments  the  valve  of  the 
eventcount  by  one  to  reflect  the  occurrence  of  the  event. 
This  has  the  effect  of  signalling  the  event's  occurrence  to 
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other  processes  which  were  waiting  for  it  by  virtue  of 
having  previously  performed  an  AWAIT  operation.  The  effect 
of  an  AT7ANCE  operation  is  essentially  the  same  as  a  Wakeup 
operation  or  Dijkstra's  "v"  operator. 

The  eventcount  signalling  mechanism  has  an  automatic 
■broadcast  effect  which  offers  an  advantage  ir.  parallel 
processing.  This  broadcast  capability  allows  the 
simultaneous  signalling  of  several  processes  which  otherwise 
would  would  have  to  be  signalled  sequentially- 
2.  Segue  nee  rs 

There  are  many  situations  where  accesses  to  shared 
resources  must  be  totally  ordered.  Eventcounts  alone  are  not 
sufficient  to  accomplish  this.  To  provide  the  capability  for 
mutual  exclusion,  another  type  of  object  called  a  sequencer 
[13]  is  employed.  A  sequencer  is  implemented  as  a  positive 
integer  ranging  in  value  from  2  to  infinity  (as  with 
eventcounts,  the  limit  is  65,536).  Fowever,  a  sequencer  is 
used  to  provide  total  order  to  the  occurrence  of  events. 
Initially  a  sequencer  has  a  value  of  2.  The  value  increases 
by  one  each  time  a  TICKET  operation  is  performed  on  it. 
TICKET  is  the  only  operation  defined  on  a  sequencer.  TICKET 
returns  a  unique  monotonically  increasing  value  with  each 
call.  Thus,  a  set  of  events  can  be  totally  ordered  by  the 
TICKET  operation. 
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3 .  Inter-Process  Synchronization 

Access  to  shared  resources  is  easily  controlled  by 
using  eventcounts  and  sequencers  in  concert,  as  shown  in  the 
following  "producer/consumer"  example  [13]  . 

Consider  that  some  hypothetical  consumer  process 
called  Printer  uses  a  single  input  buffer  in  which  it  finds 
information  to  be  processed  (output  to  the  printer^  .  There 
are  also  an  unknown  number  of  producer  processes  called 
PFOn ,  PF0E2,  etc.,  which  have  information  that  they  want 
Printer  to  output  for  them.  Obviously,  with  a  single  buffer, 
only  one  of  the  processes  can  use  the  buffer  at  any  one 
time.  The  solution  uses  one  sequencer  and  two  eventcounts  to 
properly  mediate  access  to  the  buffer  using  mutual 
exclusion. 

The  sequencer  Turn  is  used  by  the  producer  processes 
to  synchronize  their  use  of  the  input  buffer.  The 
eventcounts  Full  and  Empty  are  used  to  synchronize  with 
Printer.  Each  of  the  producer  processes  will  execute  the 
program  shown  below. 


PF0D1,  PHGD2,  etc.  /*  Producer  programs  */ 

CO  * 

T  =  TICKET(TURN);  /*  Get  a  "ticket"  (turn)  */ 

/*  for  the  buffer  */ 

AWAIT (EMFTY,T);  /*  Wait  for  buffer  ready  */ 

.  /*  Write  into  the  buffer  */ 

ADVANCE (FULL) ;  /*  Signal  Printer  that  */ 

/*  there  is  work  to  do  */ 

end;  /*  do  */ 
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Each  of  the  producer  processes  first  performs  a 
TICKET  operation  on  the  sequencer  Turn  to  obtain  a  "ticket" 
for  the  buffer.  Each  time  TICKET  is  called,  the  variable  T 
of  the  calling  producer  process  will  receive  a  unique  value. 
This  value  is  then  used  by  the  producer  process  as  an 
argument  for  the  cell  to  AWAIT.  It  is  the  event  (value  of 
the  eventcount  EMPTT)  for  which  the  process  will  wait.  When 
that  event  does  occur  (the  value  of  Empty,  which  is  advanced 
by  Printer,  reaches  the  value  specified  in  the  call  to 
AWAIT)  the  process  will  be  unblocked  and  may  then  proceed  to 
use  the  buffer.  When  it  has  finished,  the  process  will 
perform  an  ADVANCE  operation  on  the  eventcount  Full  to 
signal  Printer  that  there  is  information  in  the  irput 
buffer.  Since  each  producer  process  uses  the  same  sequencer. 


only  one  of  them  at  a  time 

will 

access  the  buffer. 

ffhe  consumer  process 

Printer  is  programmed 

as 

follows. 

PRINTER 

/* 

Consumer  program 

*/ 

BO  I  =  1  TO  65536 } 

/* 

Essentially  forever 

*/ 

AWAIT (FULL, I)  ! 

/* 

Wait  for  a  message  to  be 

*/ 

/* 

deposited  in  the  buffer 

*/ 

• 

• 

/* 

Perform  output  function 

*/ 

ADVAN CE( EMPTT)  ,* 

/* 

Notify  waiting  processes 

*/ 

/* 

that  the  buffer  is  now 

*/ 

/* 

available 

ENT;  /*  DO  */ 

The  Printer  process  synchronizes  on  the  eventcount 
Full  (it  waits  until  Full  is  advanced  by  some  producer 
process  that  has  finished  using  the  buffer).  After  Frirter 
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finishes  with  the  buffer,  it  performs  an  ADVANCE  operation 
on  the  eventcount  Empty.  This  notifies  the  producer  process 
that  is  "next  in  line”  that  the  buffer  is  now  available  for 
its  use. 

G.  THE  INNER  TRAFFIC  CONTROLLER 
1 .  General  Description 

The  Inner  Traffic  Controller  is  the  physical 
resource  manager.  It  is  responsible  for  physical  processor 
multiplexing.  Its  principal  data  base  is  a  table  known  as 
the  Virtual  Processor  Map. 

Each  physical  processor  has  its  own  fixed  set  of 
virtual  processors  used  in  multiplexing.  The  Inner  Traffic 
Controller  is  primarily  concerned  only  with  this  set  of 
virtual  processors.  However,  the  performance  of  system-wide 
synchronization  requires  access  to  the  rest  of  the  virtual 
processors  as  well,  so  that  signals  may  be  sent  to  other 
physical  processors.  This  is  accomplished  by  maintairing  the 
Virtual  Processor  Map  as  a  central  data  base  containing 
ertries  for  all  of  the  virtual  processors  in  the  system. 
Making  it  globally  available  facilitates  communication 
between  virtual  processors  on  a  system-wide  scale.  The 
Virtual  Processor  Map  fields  are  diagrammed  in  Figure  ?. 

The  State  field  reflects  the  present  state  of  the 
virtual  processor  and  can  be  any  of  ready,  running,  waiting, 
or  idle.  A  ready  virtual  processor  is  bound  to  a  process  and 
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is  in  contention  for  the  physical  processor.  The  running 
virtual  processor  is  that  virtual  processor  which  is 
actually  executing  a  process  on  the  physical  processor.  The 
waiting  state  reflects  physical  resource  management.  The 
idle  state  is  assumed  by  a  virtual  processor  which  has  no 
process  hound  to  it.  The  idle  state  prevents  the  assignment 
of  useless  (idle)  work  to  a  physical  processor. 

The  Friority  field  of  the  virtual  processor  is  used 
in  scheduling.  The  highest  priority  runnable  virtual 
processor  is  selected  to  run.  This  priority  is  determined  by 
the  priority  of  the  process  bound  to  the  virtual  processor. 

The  fystem  Eventcount  Identifier  and  System  Event 
Awaited  fields  are  used  in  system  level  syrchroni zati on . 

The  Stack  Segment  Register  Value  field  defines  the 
address  space  of  the  bound  process.  It  holds  the  process 
address  space  descriptor.  The  execution  state  of  the  process 
is  stored  in  the  stack  when  the  process  is  not  actually 
running.  This  is  the  value  which  is  required  to  access  the 
address  space  of  the  process,  viz.,  it  is  changed  to  swap 
processes . 

The  Preempt  Pending  Flag  is  used  for  preemptive 
scheduling.  It  serves  to  virtualize  a  hardware  interrupt 
sent  to  the  physical  processor. 

2 .  Virtual  Processor  Scheduler  (7p_Scheduler) 

This  module  is  responsible  for  making  the  scheduling 
decisions  for  virtual  processors.  It  selects  the  highest 


4« 


priority  virtual  processor  from  arrong  the  physical 
processor's  assigned  set  of  virtual  processors  and  schedules 
it.  Note  that  there  are  two  distirct  entry  points  to 


7p_Scheduler . 

The  normal  call  entry  point  is  used  by  other  Inner 
Traffic  Controller  modules  to  activate  7p_Scheduler  when  a 
virtual  processor  gives  up  the  physical  processor  on  its 
own.  The  preempt  interrupt  entry  point  is  used  in  response 
to  a  hardware  preempt  interrupt  from  another  physical 
processor . 

For  a  normal  call,  7p_Sfhedule r  sets  the 
7p_Scheduler  return  type  flag  to  indicate  that  a  normal 
call-return  sequence  is  to  be  followed  for  the  executing 
process.  The  7p_Scheduler  return  type  flag  is  used  to  keep 
track  of  the  mode  of  entry  into  7p_Scheduler  for  the 
process . 

7p_scheduler  next  searches  through  the  fixed  set  of 
virtual  processors  for  the  highest  priority  ready  virtual 
processor.  In  this  design,  the  definition  of  ready  includes 
the  combination  of  an  idle  state  and  a  pending  virtual 
preempt  interrupt.  This  allows  an  idle  virtual  processor  to 
run  so  that  it  may  field  the  interrupt  and  bind  to  a  new 
process.  The  idle  process  that  was  bound  to  the  virtual 
processor  was  essentially  useless  up  until  this  point.  It 
now  provides  an  address  space  for  the  virtual  processor  to 
execute  in  when  binding  to  a  new  process. 
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raving  selected  some  eligible  virtual  processor, 
7p_Scheduler  proceeds  to  bind  the  selected  virtual  processor 
to  the  physical  processor.  It  begin*  by  unbinding  tr.e 
currently  running  virtual  processor.  In  doing  so,  the 
7p_Scheduler  return  type  flag,  the  Stack  Poirter  Fegister 
value,  and  the  Base  Fointer  Fegister  value  are  saved  in 
known  locations  on  the  process'  stack.  The  process' 
execution  state  had  already  been  saved. 

rinding  the  selected  virtual  processor  is  begun  by 
changing  the  Stack  Segment  (SS)  Register  value  to  that  cf 
the  selected  virtual  processor.  Once  this  change  has  leer 
made,  execution  has  actually  swapped  to  the  rew  process 
address  *pace.  Finding  is  completed  by  retrieving  the 
previously  saved  Vp_Scheduler  return  type  '‘lag  for  the  new 
process,  the  Stack  Fointer  Register  value,  ar.d  the  Base 
Fointer  register  value  from  the  newly  acquired  stack. 

The  last  step  is  to  actually  check  the  V p_S chedu ler 
return  tvue  flag  to  determine  the  proper  tvpe  of  return  to 
execute  from  7o_Scheduler  for  this  process.  If  a  normal 
call-return  i*  indicated,  a  normal  return  will  be  executed 
back  through  the  calling  module.  Otherwise,  if  a  preempt 
interrupt  return  is  indicated,  an  interrupt  return  will  be 
executed  and  Check_?reempt  will  see  if  a  virtual  preempt 
interrupt  is  pending.  If  a  preem.pt  interrupt  is  found  to  be 
pending,  the  Traffic  Controller's  oreempt  handler  will  be 
i nvoked . 


a  .  Internal  Vodv  lc* 


Tnere  is  ore  interral  nodule  for  the  7irtual 
Processor  Scheduler  (7p_Scheduler).  It  is  usee  for  the 
veneration  of  hardware  preenpt  interrupts. 

(l)  Hdwr_Int 

This  module  is  called  by  the  Inner  Traffic 
C  on  t  rol  ler 's  interface  nodules  Itc_\dvar.ce  and  Ser.d_Fr‘aerr'pt. 
It  is  called  with  one  argument,  a  physical  processor 
identifier.  It  then  generates  the  required  hardware 
i nterrupt . 

7 .  Inner  Traffic  Controller  Interface  Modules 
a .  To  a  d_V  p 

This  medul®  performs  the  binding  of  a  new 
process  to  a  virtual  processor.  It  is  called  by  the  Traffic 
Controller  Scheduler  when  a  process  has  been  selected  for 
tha  virtual  processor.  Ioad_Vp  requires  two  parameters,  the 
priority  of  the  new  process  and  the  address  space  descriptor 
(  th°  Stack  Segment  Register  value).  It  then  swaps  in  the  new 
process  onto  the  virtual  processor  which  is  currently 
nunnine.  Lo  ai_7p  only  ope  rates  on  the  virtual  processor 
which  is  running  on  the  physical  processor. 

Binding  is  accomplished  by  updating  the  7irtual 
Processor  Yap.  The  Inner  Traffic  Controller  utility  function 
Itc_Pet_7p  is  used  to  obtain  the  identity  of  the  running 
virtual  processor.  When  complete,  the  virtual  processor  will 
hav®  a  new  priority  and  process  address  space  descriptor. 
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Load_Vp  completes  by  calling  7p_Scheduler  to  schedule  the 
virtual  processor. 

b .  Idle_7p 

This  function  is  Load_7p's  counterpart.  It  is 
called  ty  the  Traffic  Controller  Scheduler  in  the  event  that 
a  runnable  process  is  net  found  for  the  virtual  processor. 
In  this  case  the  virtual  processor  will  be  idled  (enter  the 
idle  state)  and  the  Idle  Process  will  be  bound  to  it.  In  the 
7irtual  Processor  hiap,  the  virtual  processor's  state  will  be 
marked  as  idle,  the  address  space  descriptor  for  the  Idle 
process  will  be  entered  in  the  Address  Space  of  Bound 
Process  field,  and  the  virtual  processor  will  be  riven  a 
high  priority.  The  idle  state  ensures  that  the  idle  process 
is  not  actually  run  (the  virtual  processor  now  has  a  high 
priority)  by  taking  the  virtual  processor  entirely  out  of 
contention  for  the  physical  processor. 

At  some  later  point,  the  virtual  processor  may 
be  placed  back  in  contention  for  resources.  This  will  occur 
when  the  virtual  processor  is  preempted.  With  the 
combination  of  an  idle  state  and  a  pending  preempt,  the 
virtual  processor  is  treated  as  a  high  priority  ready 
virtual  processor.  This  allows  the  virtual  processor  to  keep 
busy  by  expediting  its  binding  to  a  process. 

lastly  Idle_7p  calls  7p_Scheduler  in  order  to 
give  up  the  physical  processor. 
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c.  Itc_Fet_Vp 

This  is  a  "utility"  function  which  is  used  by 
Inner  Traffic  Controller  and  Traffic  Controller  modules. 
Itc_?et_Vp  searches  the  Virtual  Processor  Map  and  deternines 
the  identity  of  the  virtual  processor  that  is  currently 
running  on  the  physical  processor.  It  simply  checks  for  the 
virtual  processor  among  the  virtual  processors  assigned  to 
the  physical  processor  which  is  in  the  running  state. 
Itc_P.et_Vp  then  returns  its  result  as  a  function  value, 
(viz.,  as  in  PI/M)  in  the  AX  (accumulator)  register.  It  will 
return  either  the  identity  of  the  virtual  processor  (the 
virtual  processor's  index  in  the  Virtual  Processor  Map)  or  a 
"not  found"  error  code. 

d.  Ch®ck_F reempt 

This  module  is  called  by  Vp_Scheduler  during  the 
execution  of  an  interrupt  return.  It  checks  for  a  pending 
preempt  interrupt  meant  for  the  virtual  processor,  which  has 
been  selected  to  run  by  Vp_S chedu ler ,  by  checking  the 
virtual  processor's  Preempt  Fending  Flag  in  the  Virtual 
Processor  Map.  If  the  Preempt  Pending  Flag  is  set, 
Check_Preempt  will  reset  it  and  call  the  Traffic  Controller 
module  Tc_?e_Fandler. 

The  module  continuously  loops  as  long  as  it 
finds  the  Preempt  Pending  Flag  set.  This  is  to  ensure  that  a 
new  preempt  interrupt  which  might  arrive  before  servicing  of 
the  last  preempt  is  not  lost. 
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e.  Send_?reempt 

This  module  is  responsible  for  actually  sending 
preempt  interrupts.  It  is  called  by  the  Traffic  Controller 
Advance  nodule.  Send_?reempt  requires  two  arguments,  the 
identity  of  the  virtual  processor  which  is  to  be  preempted 
and  the  physical  processor  to  which  that  virtual  processor 
is  assigned. 

Send_Freempt  sets  the  virtual  processor's 
Preempt  Pending  Fla*  and  calls  Fdwr_Int  to  generate  a 
hardware  interrupt  for  the  physical  processor.  Kdwr_Int  is 
not  called  if  the  virtual  processor  to  be  preempted  is 
assigned  to  the  physical  processor  which  is  executing 
3end_Preempt ,  (viz.,  a  physical  processor  will  cot  issue  a 
hardware  preempt  interrupt  to  itself'. 

f.  Itc_Await 

Itc_Await  is  one  of  two  functions  which 
implements  inter-virtual  processor  synchronization  within 
the  kernel.  It  is  not  accessible  to  user  processes,  but  is 
used  by  the  system  in  the  management  of  physical  resources. 
It  allows  a  virtual  processor  to  wait  for  the  occurrence  of 
a  system  event. 

It  expects  two  input  arguments,  the  index  of  the 
even^count  in  the  System  Fventcount  Table  and  the  value  of 
the  event  to  be  awaited. 

Upon  being  invoked,  Itc_Await  locks  the  Virtual 
Processor  yap.  It  then  checks  the  current  value  of  the 
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eventcount  ,  obtained  from  the  System  Eventcount  Table, 
against  the  value  riven  in  the  call.  If  the  present  value  of 
the  eventcount  is  found  to  be  less  than  the  value  of  the 
input  argument,  then  the  virtual  processor  will  enter  the 
waiting  state  and  give  up  the  physical  processor. 

The  virtual  processor's  entry  into  the  waiting 
state  will  be  reflected  in  the  Virtual  Frocessor  Map.  The 
input  arguments  will  be  entered  in  the  Identity  of 
Eventcount  Awaited  and  the  Value  of  Eventcount  Awaited 
fields.  Finally,  the  virtual  processor  will  relinquish  the 
physical  processor  by  calling  Vp_Scheduler .  Upon  a  return 
from  Vp_Sched uler ,  the  Virtual  Processor  Map  will  be 
unlocked . 

g.  Itc_Advance 

Itc_Advance  is  used  within  the  kernel  to  signal 
the  occurrence  of  system  events.  It  is  used  with  Itc_Avait 
for  synchronization  between  virtual  processors.  It  accepts 
one  input  argument.  This  is  the  index  in  the  System 
Eventcount  Table  of  the  eventcount  to  be  advanced. 

Upon  being  invoked,  the  Virtual  Frocessor  Map  is 
locked.  The  System  Eventcount  Table  is  then  accessed  and  the 
indicated  eventcount's  value  is  incremented  by  one.  The 
resultant  value  is  then  compared  against  the  events  waited 
for  by  other  virtual  processors  which  are  synchronizing  on 
the  same  eventcount.  Those  virtual  processors  whose  Value  of 


Event  Awaited  fields  are  less  than  or  equal  to  the  current 
value  of  the  eventcount  are  made  ready. 

Itc_Advance  then  calls  Vp_Scheduler  to  schedule 
the  virtual  processor.  The  Virtual  Processor  Kap  will  be 
unlocked  upon  a  return  from  Vp_Scheduler . 

H.  THE  TRAFFIC  CONTROLLER 
1 .  General  Lescrlptlon 

The  Traffic  Controller  manages  the  execution  of  user 
processes.  It  presents  to  the  user  a  system  of  one  more 
virtual  processors  on  which  to  execute  his  processes. 

The  Traffic  Controller's  primary  data  base  is  the 
Active  Process  Table,  shown  in  Figure  3.  The  entry  for  each 
process  in  the  Active  Process  Table  contains  sufficient 
information  about  the  process  to  enable  a  virtual  processor 
to  be  bound  to  and  execute  it.  The  fields  of  the  Active 
Process  Table  are  explained  below. 

The  State  of  a  process  can  be  either  ready,  running 
or  blocked.  A  ready  process  is  one  which  is  not  yet  bound  to 
a  virtual  processor  but  is  ready  to  do  so.  A  Turning  process 
is  one  which  is  bound  to  a  virtual  processor  and,  as  far  as 
the  process  is  concerned,  executing.  The  blocked  state 
reflects  inter-process  synchronization.  A  process  enters  the 
blocked  state  when  it  realizes  that  it  can  no  longer  proceed 
and  wishes  to  give  up  its  virtual  processor  to  wait  until 
another  process  awakens  it. 
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The  Affinity  field  specifies  the  physical  processor 
that  the  process  must  execute  on.  In  this  system,  this  field 
indicates  the  specific  microcomputer  on  which  the  process  is 
current lv  loaded. 

The  Identity  Of  Bound  Virtual  Frocessor  serves  to 
identify  the  virtual  processor,  if  any,  that  the  process  is 
currently  hound  to. 

The  Priority  specifies  the  priority  of  the  process. 
In  this  system,  priorities  ranee  in  value  from  £  to  255, 
with  a  priority  of  E  being  the  highest. 

The  loaded  list  Thread  field  serves  to  implement  the 
Loaded  list  of  ready  and  running  processes.  It  contains  a 
pointer  to  the  next  process  in  the  Active  Process  Table 
which  is  loaded  on  the  same  microcomputer  as  this  process. 
The  loaded  list  is  ordered  by  the  priorities  of  the 
processes.  Thus  this  field  contains  either  a  pointer  to  a 
process  whose  priority  is  less  than  or  equal  to  that  of  this 
process  or  a  nil  pointer  (viz.,  the  last  process  on  the 
Loaded  List). 

The  Value  Of  Sveatcount  Awaited  reflects  the  event 
for  which  the  process  has  blocked  itself.  It  contains  the 
value  that  the  process  is  waiting  for  the  eventcornt  to 
reach . 

The  Block  List  Thread  is  used  to  implement  the 
Blocked  list.  This  is  a  per  eventcount  list  of  processes 
which  are  waiting  on  the  eventcount. 
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The  Address  Space  Descriptor  field  contairs  tne 
process'  address  space  descriptor.  This  is  the  identity  of 
the  process'  stack  which  contains  execution  point 
information.  The  value  used  here  is  the  base  location  In 
memory  of  the  stack  segment,  viz.,  the  Stack  Segment  (SSI 
Register  value. 

2.  Process  Scheduler  (Scheduler) 

Scheduler  works  in  essentially  the  same  way  that  the 
Inner  Traffic  Controller's  Vp_Scheduler  does.  Fowever, 
Scheduler  works  with  processes.  Scheduler  can  be  called  by 
Advance,  Await,  Tc_Pe_Fandler ,  Create_Pvc,  Create_Seq,  and 
Create_Frocess. 

It  selects  the  highest  priority  ready  process  from 
the  microcomputer's  loaded  List  to  be  bound  to  an  available 
virtual  processor.  Scheduler  works  only  with  the  processes 
which  are  runnable  on  its  own  physical  processor  usin?  the 
fixed  set  of  virtual  processors  for  that  physical  processor. 

If  Scheduler  finds  a  runnable  process,  the  Inner 
Traffic  Controller  module  Load_Vp  is  called  to  bind  the 
selected  process  to  the  running  virtual  processor. 
Alternatively,  if  a  runnable  process  is  net  found,  the 
virtual  processor  will  be  idled  (bound  to  the  Idle  Process 
and  placed  in  the  idle  state)  by  a  call  to  the  Inner  Traffic 
Controller  module  Idle_Vp. 

In  its  present  form,  Scheduler  has  only  one  entry 
point,  a  call  entry  point.  There  is  no  interrupt  entry  point 
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a?  there  is  in  Vp_Scheduler.  This  was  done  as  an  expedient 
in  this  design  effort.  It  is  desireatle  to  provide  the 
second  entry  poiEt  so  that  the  two  schedulers  have  parallel 
structures.  Because  there  is  no  interrupt  entry  point,  there 
is  a  loop  between  the  Inner  Traffic  Controller  and  the 
Traffic  Controller  for  the  handling  of  preenpt  interrupts. 
This  is  due  to  the  call  from  the  Inner  Traffic  Controller's 
preempt  handler  Check_Pre_2mpt  to  the  Traffic  Controller's 
preempt  handler  Tc_Pe_Handler . 
a.  Internal  Modules 

There  are  two  "utility"  modules  internal  to  the 
Scheduler  that  are  used  only  by  Traffic  Controller  modules. 
They  are  used  to  simplify  the  handling  of  even tcounts  and 
sequence rs  . 

(1)  Locate_Evc.  This  "utility"  returns  the  Index 
of  an  eventcount  in  the  Eventcount  Table.  It  is  called  by 
Advance,  Await  and  Ticket  with  (a  pointer  to)  the  name  of 
the  eventcount.  Iocate_Pvc  then  attempts  to  match  the  name 
given  to  it  with  one  in  the  Eventcount  Table.  If  a  match  is 
found,  it  returns  the  index  to  the  caller  in  the  AX 
(Accumulator)  Register  as  a  function  value  (viz.,  as  in 
PI/M). 

(2)  Iocate_Seq.  This  is  the  second  Traffic 
Controller  "utility"  function.  It  works  in  exactly  the  sane 
way  that  Locate_Evc  does  except  that  it  searches  for 
sequencers  in  the  Sequencer  Table  rather  than  ev°ntccur.ts  . 
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3.  Traffic  Controller  Interface  Modules 


a.  Await 

Await  allows  a  process  to  suspend  its  execution 
pending  the  occurrence  of  a  specified  event.  AVAIT  is  called 
with  two  arguments,  (a  pointer  to)  the  name  of  the 
eventcount  and  the  value  (of  the  event)  to  he  awaited. 

TJpon  invocation.  Await  locks  the  Active  Process 
Table  and  then  calls  the  Inner  Traffic  Controller  utility 
function  Itc_Ret_Vp  to  obtain  the  identity  of  the  running 
virtual  processor.  This  is  used  in  a  search  of  the  Active 
Process  Table  to  identify  the  calling  process. 

Once  the  calling  process  has  been  identified, 

f 

the  current  value  of  the  eventcount  is  compared  to  the 
awaited  value  specified  in  the  call.  If  the  event  has  not 
yet  occurred,  (viz.,  the  current  value  is  less  than  the 
value  to  be  awaited),  then  the  process  will  enter  the 
blocked  state.  The  Value  of  Fventcount  Awaited  field  in  the 
Active  Process  Table  is  updated  with  the  value  awaited 
argument  and  the  process  is  placed  on  the  eventcount 's 
Blocked  List.  If  the  event  has  already  occurred,  (viz.,  the 
current  value  is  greater  than  or  equal  to  the  value  awaited 
argument),  then  the  process  is  not  blocked  but  is  made 
ready. 

Await  next  calls  Scheduler.  The  Active  Process 
Table  is  unlocked  upon  the  return  from  Scheduler. 
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b.  Advance 

Advance  allows  a  process  to  signal  the  occurrence 
of  an  event.  It  updates  the  eventcount  and  signals  those 

processes  which  had  blocked  themselves  for  this  event.  Thus 

Advance  is  responsible  for  preemption. 

Advance  is  called  with  one  argument,  (a  pointer 
to)  the  name  of  the  eventcount  being  advanced. 

It  first  locks  the  Active  Process  Table.  Then  the 
current  value  of  the  eventcount  is  incremented.  The 

eventcount 's  Blocked  List  is  searched  for  processes  which 

had  previously  blocked  themselves  for  this  value.  As 
processes  are  found  that  should  be  awakened,  th^y  are  made 
ready.  An  entry  in  a  temporary  array  of  physical  processors 
is  now  made  to  flae  the  physical  processor,  in  whose  local 
memory  the  newly  awakened  process  is  loaded,  for  preemption. 

The  awakened  process  is  then  removed  from  the  eventcount 's 
Blocked  List. 

Once  all  of  the  processes  to  be  awakened  have 
been  found,  Advance  determines  which  virtual  processors  must 
be  preempted.  This  is  done  for  each  of  the  previously 
flagged  physical  processors  by  first  assuming  that  all  of 
the  physical  processor's  virtual  processors  should  be 
preempted.  Then  the  decision  is  made  as  to  which  ones  will 
not  be  preempted.  This  method  greatly  simplifies  the 
alsorithm.  First  a  temporary  list  (array)  of  virtual 
processors  is  initialized  to  indicate  a  virtual  preempt  for 
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each  of  the  virtual  processors.  The  Loaded  List  is  then 
searched  to  find  those  processes  which  should  he  running. 
The  processes  which  should  he  running  are  those  with  the 
highest  priorities  that  are  in  either  the  ready  or  the 
running  states.  Assuming  there  are  2  virtual  processors  per 
physical  processor  used  for  multiplexing,  the  2  highest 
priority  ready  or  running  processes  in  the  loaded  list 
should  he  running.  Any  lower  priority  processes  that 
actually  are  running  should  he  preempted.  Advance  determines 
which  of  the  processes  that  should  he  running  already  are 
running  and  deletes  their  virtual  processors  from  the 
preemption  list  (resets  the  preempt  flag  in  the  array').  Vhat 
will  remain  at  the  end  are  those  virtual  processors  that  are 
to  he  preempted. 

The  next  step  is  to  actually  issue  the  preempt 
interrupts.  The  temporary  preempt  list  is  checked  and  if  a 
preempt  is  Indicated  for  a  virtual  processor,  the  Inner 
Traffic  Controller  module  Send_?reempt  is  called  to  artually 
issue  the  preempt. 

Advance  next  readies  the  calling  process  and 
calls  Scheduler.  Upon  the  return  from  the  call  to  Scheduler 
the  Active  Process  Table  is  unlocked, 
c.  Ticket 

Ticket  returns  a  unique  sequencer  value  with 
every  invokation.  The  value  returned  will  always  he  one  more 
than  the  last  value  returned. 
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It  is  called  with  one  argument,  fa  pointer  to^ 
the  sequencer  name.  When  invoked.  Ticket  asserts  the  global 
lock  on  the  Active  Process  Table,  effectively  locking  the 
Sequencer  Table.  Ticket  then  calls  Locate_Seq  with  the 
pointer  to  the  sequencer  name  given  to  it  as  an  input 

argument  and  gets  back  the  index  of  the  sequencer  in  the 

Sequencer  Table.  It  ♦'hen  obtains  the  sequencer's  value  which 
is  to  be  returned  to  the  calling  module  in  the  AX 

( Accumulat or )  Register  following  standard  FI/M  conventions. 
Before  returning,  ticket  increments  the  value  of  the 

sequencer  and  unlocks  the  Active  Process  Table. 

Note  that  Ticket  does  net  call  Scheduler  like  the 
other  synchronization  primitives  Advance  and  Await.  Ticket 
returns  immediately  from  a  call, 
d.  Read 

Read  returns  the  current  value  of  an  eventccunt. 
It  is  called  with  one  argument,  (a  pointer  to>  the  name  of 
the  ever.tcount. 

When  called,  Read  locks  the  Active  Process  Table, 
so  as  to  lock  the  Eventccunt  Table.  It  then  calls  Locate_Evc 
to  obtain  the  index  of  the  eventcount  in  the  Ever.tcount 
Table.  With  this  index.  Read  obtains  the  value  of  the 
eventcount  and  returns  the  value  in  the  AX  (Accumulator) 
Register  following  normal  PI/M  conventions.  Prior  to 
returning.  Read  unlocks  the  Active  Process  Table. 
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e.  Tc_?e_Hand ler 

This  module  serves  as  the  virtual  preempt 
interrupt  entry  point  into  Scheduler.  It  is  called  tv  the 
Inner  Traffic  controller's  7 p_S cheduler  in  the  course  of 
handling  preempt  interrupts. 

Tc_?e_Fandler  calls  Scheduler  to  find  the  highest 
priority  ready  process  to  bind  to  the  pre-empted  virtual 
processor . 

f.  Create_Evc 

This  module  creates  an  eventcount  for  a  user 
process.  Create_Evc  is  called  with  one  argument,  (a  pointer 
to)  the  name  of  the  eventcount  to  be  created. 

Upon  being  invoked,  Create_Evc  locks  the  Active 
Process  Table,  which  effectively  locks  the  Eventcour.t  Table. 
It  then  calls  Locate_Evc  to  determine  whether  or  not  the 
eventcount  had  already  been  created.  This  is  to  avoid  raking 
duplicate  entries  (since  each  process  which  will  use  the 
eventcount  rust  declare  at  least  the  name).  If  tne 
eventcount  had  not  previously  been  created  (viz.,  no  entry 
is  found  i  r.  the  Eventcount  Table  with  the  sare  name  as  elver, 
in  the  input  argument)  then  an  entry  is  made  in  the 
Eventcount  Table.  The  name  is  copied  into  the  Eventcount 
Table  and  the  eventcount's  current  value  is  initialized  to 
£.  Otherwise,  no  entry  is  made,  lastly,  it  unlocks  the 


Active  Process  Table  prior  to  returning. 


g.  Create_Seq 

This  module  creates  a  sequencer  for  a  user 
process.  Create_Seq  performs  in  exactly  the  same  way  as 
Create_Svc  (paragraph  f)  except  that  it  creates  sequencers 
rather  than  eventcounts. 

h.  Create_?rccess 

Crea te_Process  provides  the  capability  to 
dynamically  create  processes.  It  is  called  with  one 
argument,  a  pointer  to  a  process  parameter  Hock  containing 
all  the  information  necessary  to  initialize  the  process's 
stack  and  enter  the  newly  created  process  into  the  Active 
Process  Table.  All  of  the  process's  segments  had  previously 
been  loaded  into  memory  by  the  system  loader,  Foss  [16]. 

Crea te_Process  first  locks  the  Active  Process 
Table.  It  then  creates  tire -injLtiHizaton  stack  frame.  The 
process  parameter  block  contains  all  of  the  intTi-a-l  -register 
values  (viz.,  initial  values  for  all  of  the  £P£6's 
registers)  for  the  process.  These  are  stored  in  the 
initialization  stack  frame?  the  location  of  the  stack  is 
specified  in  the  Process  Parameter  Block.  The  next  step  is 
to  create  the  Active  Process  Table  entry  for  the  process. 
The  affinity,  priority  and  Stack  Segment  (SS)  Register  value 
are  then  entered  in  the  Active  Process  Table.  lastly, 
Create_F rocess  determines  where  this  process  should  be 
Inserted  into  the  Load  list  based  on  it?  priority. 
C rea te_? roces s  inserts  the  process  into  the  Load  List  (viz.. 
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sets  the  Load  Thread  in  the  Active  Process  Table) 
immediately  ahead  of  the  first  process  it  finds  in  searching 
down  the  Loadilist  whose  priority  is  less  than  or  equal  to 
the  newly  created  pro  cess.  Finally,  the  Active  Process  Table 
is  unlocked  and  execution  returns  to  the  caller.  Note  that 
the  Scheduler  is  net  called. 

I .  THE  SUPERVISOR 

In  a  general-purpose  operating  system  the  Sup-.- rvi  sor 
provides  common  services  such  as  library  routines,  linkers, 
various  development  tools  and  a  file  sytem.  It  also  acts  as 
the  interface  between  user  programs  and  the  kernel. 

1 .  General  Pescription 

At  this  state  of  the  design,  only  one  module  resides 
at  this  level,  a  higher  order  language  interface  to  the 
operating  system  kernel.  This  module  (called  the  Gate)  is 
constructed  such  that  it  is  the  only  operating  system  module 
that  the  user  must  link  to  his  processes  to  access  kernel 
functions . 

The  Gate  contains  the  actual  linkages  (viz.,  Global 
procedure  declarations)  for  all  of  the  kernel  functions. 
This  allows  the  user  to  directly  call  on  various  kernel 
services  without  using  absolute  addresses  that  car  change  as 
the  kernel  continues  to  be  developed.  This  structure  allows 
the  users  and  the  operating  system  developers  to  continue 
their  work  independently  without  requiring  the  users  to 
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continually  change  their  programs  to  accommodate  changes  in 
the  kernel. 

2 .  Supervisor  Invocation  (The  Gate) 

The  C-ate  is  actually  a  set  of  global  (vi?.,  PL  >Y 
PUBLICS  procedure  declarations  which  the  user  programs  can 
call  directly.  Each  of  the  user  accessible  kernel  fractions 
is  represented  by  one  of  these  "procedures".  In  reality, 
they  simply  set  up  the  required  parameters  ard  us°  a  trap 
feature  to  effect  the  call  to  the  "real"  procedure  of  the 
same  name  residing  in  the  kernel. 

The  Gate  is  written  in  assembly  language  because  of 
the  stack  manipulation  that  must  be  done  to  enable  the  trap 
handler  to  1)  determine  the  correct  kernel  procedure  to 
call,  and  2)  properly  pass  parameters  to  the  kernel 
procedures.  The  trap  handler  in  the  kernel  is  an  assembly 
language  module  as  well.  If  the  trap  handler  were  written  in 
Pl/y,  parameters  would  nave  to  be  somehow  giver,  to  it 
explicitly  prior  to  its  calling  on  the  kernel  procedure. 
Since  the  trap  handler  is  reached  by  an  interrupt  rather 
than  a  call,  this  is  not  possible.  Instead,  the  parameters 
a  re  moved  on  the  stack  to  a  position  where  they  before 
parameters  for  the  call  by  the  trap  handler  to  the  kernel 
procedu  re . 

This  has  the  effect  of  de-coupling  the  user  fr*m  all 
of  the  operating  system  modules  below  the  level  of  the 
Supervi sor . 
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7.  CONCLUSIONS 


A.  SUMMARY  OF  RESULTS 

The  principal  goal  of  this  effort  is  the  devel o pment  of 
a  multiple  processor  system.  A  parallel  development  effort 
in  secure  systems,  Reitz  [12],  utilized  the  O'Connell  and 
Richardson  design  as  the  basis  for  the  kernel  of  a  secure 
computer  system  utilizing  the  Zilcg  "?£££  microprocessor. 
The  detailed  designs  of  the  kernels  of  both  of  these  systems 
is  nearly  identical,  at  least  at  the  level  of  kernel  module 
interfaces.  In  both  development  efforts,  no  conceptual 
problems  were  encountered.  Thus  the  O'Connell  and  Richardson 
design  has  been  found  to  be  consistent  for  multiple 
processors  and  secure  computer  systems. 

System  initialization  [16],  introduced  a  number  of 
design  changes.  However,  these  had  no  adverse  effect  on  the 
design  or  the  system.  Their  integration  is  not  a  simple 
matter  as  they  impact  on  the  stack  format,  and  the  design  of 
the  process  scheduler  and  virtual  processor  scheduler  in 
that  the  accommodation  of  preempt  interrupts  is  somewhat 
more  difficult. 

Another  of  the  objectives  is  to  test  the  viability  of 
utilizing  gpneral-purpose,  commercial  microcomputer  systems 
as  the  basic  building  blocks  of  multiple  computer  systems. 
It  has  been  found  that  sufficiently  developed  microcomputer 
svstems  are  available  in  industry.  Further,  it  was 
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determined  that  enough  hardware  support  (busses,  I/O 
devices,  peripherals)  is  available  to  construct  multiple 
computer  systems  without  major  hardware  development  efforts. 

The  state  of  the  art  in  microcomputer  software 
development  was  found  to  be  less  amenable.  Such  useful  tools 
as  high  level  languages,  assemblers,  etc.  are  available  but 
they  are  generally  limited  to  use  with  uniprocessor 
developmental  systems.  Additionally,  most  commercially 
available  software  development  tools  are  highly  machine 
dependent.  Specifically,  they  require  low-level  monitors  or 
special  hardware  that  are  only  available  on  a  development 
system.  Thus  there  is  little  hope  of  easily  modifying  these 
tools  to  run  on  a  different  system  tha"  was  intended  by  the 
vendor,  particularly  since  details  of  their  structure  and 
operation  are  proprietary. 

A.  FURTHER  RESEARCH 

Further  development  work  is  still  required.  This 
includes  the  final  construction  of  the  Crate  and  the 
inclusion  cf  two  n on-d i s t ri bu ted  kernel  processes  for  I/O 
and  memory  management.  These  kernel  processes  provide  for 
the  virtualization  of  memory  and  I/O  resources  with  which  to 
achieve  the  goal  of  configuration  independence. 

The  present  design  utilizes  the  test-and-set  semaphore 
operation  to  implement  global  locks  on  kernel  data  bases 
(viz.,  the  Active  Process  Table  and  the  Virtual  Processor 
Map).  This  mechanism  (supported  by  the  PI/M  built-in 
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procedure  "lockset"  [5])  is  a  spin-lock  witi^  potentially 
significant  impact  on  system  bus  traffic.  This  mechanism 
should  be  replaced  by  the  Inner  Traffic  Controller 
synchroni cation  primitives  wherever  possible  to  avoid  the 
overhead  of  "busy-waiting". 

This  detailed  design  is  considered  to  be  only  a  first 
step  in  the  development  of  a  general-purpose  multiple 
microcomputer  system.  O'Connell  and  Richardson's  design 
offers  some  exciting  opportunities  to  pursue  development 
efforts  in  the  areas  of  secure  computer  systens  and  fault 
tolerance . 
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APPENDIX  A  -  PROGRAMS  IMG 


A.  I  MTPOEtICT  ION 

This  appendix  is  designed  to  he  a  practical  introduction 
to  programming  methodology  for  this  system. 

Pecause  there  are  multiple  processors,  a  number  of 
concepts  and  methodologies  will  necessarily  be  introduced 
which  may  at  first  be  uncomfortable.  This  is  especially  true 
if  one  is  firmly  entrenched  in  the  traditional  concepts  of 
the  monolithic,  sequential  program  structure.  However,  as 
one  makes  the  transition  to  the  concepts  of  process 
structuring,  it  will  be  seen  to  be  a  natural  approach  to  the 
development  of  complex  software  systems.  Additionally,  it  is 
essential  to  the  effective  use  of  multiple  processor 
systems . 

Parallelism  immediately  presents  the  programmer  with  an 
entirely  new  set  of  complexities.  He  is  not  limited  tc  tne 
strictly  sequential  execution  of  program  statements  in  a 
single  program.  Exercising  control  over  the  order  and  ti^inp 
of  execution  of  multiple  processes  becomes  a  major  part  of 
the  programming  effort.  Inter-process  synchrcni zation,  the 
mechanism  by  which  processes  are  controlled,  is  the  most 
difficult  concept  which  the  user  will  tc  required  tc  deal 


with.  However,  the  synchronization  primitives  built  into  the 
operating  system  are  designed  tc  make  this  as  simple  and 
straightforward  as  possible. 

It  is  assumed  that  the  primary  programming  language  for 
this  system  will  he  Intel's  FI/M-3 6  [5,  12].  This  is  a 
powerful,  block  structured  high  level  language  designed  for 
systems  programming.  This  apoendix  is  written  assuming  that 
the  reader  will  program  in  ?L/if-66  and  is  familiar  with  its 
terminology  and  notation.  All  of  the  examples  make  use  of  ar. 
informal  PI /y  notation. 

i.  THE  PROCESS  STRUCTURE 

Consider  the  rather  typical  ?L/g  program  module  of 
Figure. 9.  It  contains  three  procedure  declarations  and  some 
mainline  statements.  Each  of  the  procedures  will  execute 
when  called  from  the  mainline  and,  upon  completion,  will 
return  control  back  to  the  mainline. 

A  single  program  is  what  most  users  are  familiar  with 
and  is  a  structure  which  can  be  dealt  with  easily.  However, 
as  the  computing  task  grows  to  any  real  size  and  complexity, 
this  single  program  grows  equally  large  and  complex.  The 
result  is  a  huge  program  with  a  myriad  of  procedures  that 
can  only  be  called  Sequentially  to  perform  necessary 
functions.  Thus  this  structure  dees  not  allow  taking 
advantage  of  the  performance  gain  that  parallel  processing 
can  offer. 
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Program  Module  A:  To? 


A1  :  PROCEDURE  /*  Declaraticr.  */ 

do; 


end; 

END;  /*  Frocedure  A1  */ 

A2:  PROCEDURE;  /*  Declaration  */ 

do; 


end; 

end;  /*  Procedure  A2  */ 

A?:  PROCEDURE;  /*  Declaration  */ 

do; 


• 

r»i»  -n  • 
iJ  9 

END;  /*  Procedure  A3  */ 

DO;  /*  Begin  Mainline  */ 

CALL  AIJ 
CALI  A2; 

CALL  A3; 

END?  /*  Mainline  */ 

END;  /*  Prograrr,  Module  A  */ 


EXAMPLE  PL/M-36  PROGRAM 


Figure  9 
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The  principal  advantages  of  the  process  structure  lie  in 
the  ability  to  utilize  multiple  processes  ar,  d  tc 
independently  construct  individual  compo nen ts  of  software 
subsystems,  viz.,  processes.  Rather  than  using:  a  single 
process  to  accomplish  the  entire  job  as  in  Figure  9 ,  the 
overall  task  can  be  partitioned  and  accomplished  by  a  number 
of  smaller  cooperating  processes.  Rach  of  these  processes 
can  be  smaller  than  the  single  monolithic  program  and  so  is 
easier  to  design,  implement  and  test.  This  allows  entire 
processes  (each  a  distinct  program!  tc  be  developed  and 
tested  semi- independently  in  a  manner  similar  to  the 
development  and  testing  of  individual  procedures  in  a  sing'le 
PL/*!  program. 

Control  over  processing  functions  is  also  much  more 
flexible.  One  is  not  forced  into  a  strictly  sequential 
series  of  procedure  calls.  Many  processes  can  be  allowed  to 
execute  in  parallel,  which  can  bring  about  dramatic  gains  in 
overall  performance. 

Figure  1C  is  a  simple  example  of  the  flow  cf  execution 
in  a  system  with  three  processes.  The  three  processes 
perform  exactly  the  same  functiors  as  the  three  procedures 
of  Figure  9  and  so  bear  the  same  names.  In  this  example  the 
processes  execute  sequentially,  one  after  the  other  in  a  set 
order.  Processing  goes  on  forever  in  this  "loop".  Frccess  A2 
will  only  begin  executing  after  it  has  been  somehow 
"signalled"  by  process  A1 .  The  same  is  true  of  process  A? 
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whose  execution  is  synchronized  with  process  A2.  Obviously, 
there  rust  be  sore  control  mechanism  that  allows  these 
processes  to  do  this. 

C.  INTFR-RROCFSS  SYNCHRONIZATION  YECFAN IS YS 

The  ability  to  synchronize  the  execution  of  processes 
throughout  the  system,  (irrespective  of  which  microcomputer 
they  are  loaded  on),  is  the  cornerstone  of  the  power  and 
flexibility  of  this  system.  To  accomplish  this,  process 
svnchronization  is  based  on  the  notion  of  events. 

1.  Events 

An  event  is  anything  that  one  considers  significant 
and  can  direct,  in  some  fashion,  the  corputer  to  respond  to. 
As  an  example,  consider  a  clock  which  indicates  a  time  of 
twelve  o'clock.  The  computer  has  no  inherent  conception  of 
time.  As  far  as  it  is  concerned,  time  may  be  nothing  more 
than  a  value  in  some  register.  In  some  way,  then,  time  must 
be  defined  for  the  computer.  This  is  accomplished  by 
translating  the  occurrence  of  twelve  o'clock  into  an  event. 

I 

^  When  the  event  occurs,  the  computer  recognizes  that  it  is  to 

^  respond  in  some  specified  manner. 

i  Events  are  defined  so  as  to  be  very  general  in 

‘  nature.  They  can  be  used  to  represent  the  completion  of  a 

program,  as  in  the  completion  of  process  A1  in  Figure  1? 
which  started  tne  execution  of  process  A2.  They  ecu 
represent  virtually  anything  of  interest  to  the  programmer, 

i 

■  * 

L-i 
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at  least  anything  that  he  car.  identify  as  being  of 
sinnif i cance  . 

2.  Zventcounts  and  Sequencers 

Zventcounts  and  sequencers  allow  processes  to 
synchronize  with  each  other  somewhat  indirectly.  To 
synchronize  directly,  a  process  would  have  to  somehow 
identify  the  other  processes  with  which  it  is  synchronizing 
(viz.,  explicitly  signal  a  process  by  nane'.  This  would 
require  the  naming  of  individual  processes  or  some  similar 
identification  scheme. 

Rather  than  using  a  process  naming  scheme,  the 
individual  processes  "agree”,  in  a  sense,  to  cooperate  by 
using  a  common  set  of  memory  objects  called  eventccunts  ar.d 
sequencers.  In  this  way,  even  though  the  processes  must  know 
the  names  of  the  eventcounts  and  sequencers  that  they  use, 
they  are  not  required  to  know  anything  at  all  about  each 
other's  identities.  In  fact,  a  process  need  not  even  know 
how  many  other  processes  will  the  synchronizing  with  it. 
This  offers  some  advantages  in  parallel  processing. 
Processes  that  synchronize  with  eventcounts  do  not  have  to 
snow  how  many  other  processes  will  also  use  the  same 
eventcounts.  This  means  that  fewer  coding  changes  will  be 
required  when,  for  example,  a  single  process  is  partitioned 
into  several  processes  all  executing  in  parallel.  All  of  the 
"new”  processes  will  syncnronize  cr.  the  same  ever.trour.t  sc 


: hat  no  change?  are  required  in  the  process  that  orifi'lr.aIly 
synchronized  with  the  single  process. 

Fvertcounts  are  used  to  keep  track  of  the  occurrence 
of  specific  events.  They  are  managed  for  the  user  by  the 
system.  iventcounts  are  implemented  as  FI /V-C5  wcrd 
variables  rane'i  nf:  in  value  from  C  to  65535 .  Sequencers  are 
also  implemented  as  FI/Ni-£5  word  variables  random  in  value 
from  ?  to  6553c.  However,  sequencers  can  be  us3i  tc  impose 
an  order  on  the  occurrence  of  events.  They  are  thus  used 
with  eventcounts  to  provide  for  mutual  exclusion. 

3.  Fventcour.t  and  Sequencer  Federations 

a.  T^clarir.s:  Fventcount  and  Sequencer  Names 

Fventcounts  anc  sequencers  are  named  usirv  a 
bytp  array  cf  alpnanumeric  characters.  The  format  for 
declaring  ar.  eventcou.nt  or  sequencer  name  is  fiver.  in  Figure 
11.  Note  that  the  names  are  constants,  not  vadables.  Tr. 'e 
declared,  a  rare  must  not  chaiif®.  Tver,  treur.  t  anJ  sequencer 
nares  consist  of  5  characters  followed  by  a  per  cent  symbol 
[%) .  Note  in  Figure  11  tr.at  the  name  of  the  byte  array  ,-ust 
be  the  same  as  the  string  constant  dven  in  the  FATA 
Initialization.  This  allows  the  user  to  reference  the 
eventcount  or  sequencer  by  r.ane  and  aliow«  the  operating 
system  to  identify  it. 

Rerember  that  tne  names  of  ever  t  co’T.  t*  and 
sequ°ncers  rust  be  declared  in  exactly  the  same  way  ir.  each 
?L/v-65  module  ir.  which  they  will  be  usd. 
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t.  Passing  "ventcount  and  Sequencer  Na-es 

When  calling  the  operating  sy  s  ter 

synchronization  priritives,  eventcount  and  sequencer  names 
are  always  passed  as  rl/M-co  location  references  usin.-?  the 
operator.  As  an  example,  consider  that  a  byte  array 
called  "NA.'tPl"  holds  the  s  trine  "‘JAY  21*"  'note  that  the  "V 
symbol  is  only  a  delimiter  and  is  not  considered  to  he  part 
of  the  nape).  To  pass  the  name  in  a  call  to  an  o  p  c  r  a  t  i ? 
system  synchronization  primitive,  then,  the  pararetor 
"PMAh'Sl”  is  used.  With  the  pointer  so  given,  the  operating 
system  can  ’read"  the  name  directly  from  the  array, 
c.  Creating  Tventcounts  and  Sequencers 

Tefore  an  eventcount  or  a  sequencer  is  used,  the 
operating  system  must  be  informed  of  its  existence.  This  is 
accomplished  by  a  call  to  the  operating  system  procedures 
CPZATUiSVC  (for  eventcourts)  and  C?.2AT7dS7C  (for 
sequencers).  The  format  of  these  operations  is  *hpvn  in 
Figures  12  and  id.  There  is  only  one  argument  "or  either  of 
the  calls,  the  pointer  to  the  previously  declared  name.  When 
created,  an  eventcount  or  a  sequencer  will  always  he 
initialized  with  a  starting  value  of  2. 

4.  Synchronization 

Fventccunts  and  sequencers  are  utilized  by  means  of 
a  set  of  operations  which  may  be  performed  or.  the-.  The  user 
cannot  directly  perform  operations  or.  either  even  t  r  r  u  r.  t  s  or 
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sequencers,  tut  rather  calls  on  certain  operating  system 
primitives  to  lo  these  for  him. 

a.  Operations  on  Eventccunts 

There  are  three  operations  that  one  can  perform 
on  eventcounts.  They  are  ADVANCE,  AWAIT  and  RE AT.  A.R7ANCE 
and  AWAIT  are  untyped  procedures.  REAL  is  a  value  returning 
typed  procedure  (function  call)  that  returns  a  RL/'l-ES  word 
value  to  the  calling  process. 

An  example  of  a  REAR  operation  is  given  in 
Figure  14.  The  READ  operation  allows  tne  user  to  obtain  the 
current  value  of  a  specified  eventcount.  REAR  returns  the 
eventccunt's  value  in  the  AX  Register  (in  accordance  with 
normal  FL/K-E6  conventions).  Thu?  a  process  calls  FEAR  with 
the  name  of  the  eventcount  as  the  argument  and  gets  back  the 
eventcount 's  current  value.  Mote  in  Figure  14  that  the 
current  value  of  eventcount  EVENT  is  returned  to  the 
user-def  i r.ed  word  variable  "WDRRiVARIABIE"  . 

The  AWAIT  operation.  Figure  15.  is  used  ly  a 
process  to  block  itself  (suspend  its  execution)  until  the 
eventcount  reaches  the  value  specified  in  the  call.  AWAIT 
requires  two  arguments,  the  eventcount  name  and  the  event 
(actually  the  value  of  the  eventcount)  to  wait  for.  The 
value  for  which  the  process  will  wait  must  be  a  ?I/v-cF  word 
value.  This  allows  the  process  to  synchronize 


itself 


with 


"iCHE^V  AH  I  API?  =  ?FAD(  OEVENT  '  * 

THE  READ  OPERATION 
Figure  14 

CALI  AWAIT ( 0EVENT ,VALUE$TO$A*AlT 1  ; 

THE  AWAIT  OPERATION 
Figure  15 

CALL  ADVANCE  (GE7ENT),* 

THE  ADVANCE  OPERATION 
Figure  16 

WORD ^VARIABLE  =  TICKET (GNAME1 )  ? 

THE  TICKET  OPERATION 
Figure  IT 


33 


oth<=r  processes  by  waiting,  for  instance,  until  a  set  of 
data  is  ready  for  it  to  use. 

The  ADVANCE  operation.  Figure  16,  is  used  to 
signal  the  occurrence  of  an  event.  ADVANCE  onlv  requires  one 
argument,  the  name  of  the  eventcour.t  to  be  advanced,  './her.  it 
is  called,  it  will  cause  the  value  of  the  eventcount  to  be 
incremented  by  one.  The  operating  system  will  then  proceed 
to  unblock  those  processes  that  were  waiting  for  the 
eventcount  to  reach  the  current  value  (by  virtue  of  having 
previously  called  AWAIT). 

b.  Operations  on  Sequencers 

There  is  only  one  cp°  ra  t i or  that  can  be 
performed  on  sequencers.  It  is  called  TICKET,  Figure  17. 
TICXFT  is  a  value  returning  typed  procedure  (function  call) 
similar  to  the  HEAD  operation  for  even tcouct s .  However, 
TICKET  returns  to  the  caller  a  unique  sequencer  value.  The 
current  value  of  the  sequencer  is  returned  to  the  caller  a  r.d 
then  the  sequencer  is  incremented  by  one  for  the  next  caller 
time  a  TICKET  operation  is  performed  on  it.  This  will  be 
true  irrespective  of  how  many  different  processes  perform 
the  TICKET  operations.  In  this  way  TICKET  provides  the 
totally  ordered  set  of  values  for  use  by  multiple  processes 
in  effecting  mutual  exclusion. 
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5.  Synchronization  Examples 

a.  Sequential  Processing  Example 

F igure  IS  provides  a  detailed  example  of  how  a 
process  would  be  programmed  to  actually  create  and  use 
eventcounts  for  synchronization.  The  program  shewn  here  is 
actually  process  A1  of  Figure  1?. 

Referring  to  the  flow  of  control  in  Figure  IF, 
it  can  be  seen  that  process  A2  will  begin  execution  when 
signalled  by  Al.  Similarly  process  A3  will  begin  when 
signalled  by  A2.  Finally,  when  A3  signals  its  completion, 
the  "loop"  starts  over  again  with  process  Al .  This  is 
reflected  in  the  sample  program  for  process  Al,  Figure  IF. 
Here  two  eventcounts  are  declared  and  created,  "ENEAl"  and 
"ENEA3".  Eventcount  ENEAl  is  used  to  synchronize  with 
process  A2.  Specifically,  ENDA1  refers  to  the  event 
corresponding  to  the  completion  of  Al 's  processing  task.  The 
occurrence  of  this  event  is  signalled  to  process  A2  through 
the  Advance  operation  performed  or  eventcount  ENDA1  (located 
at  the  end  of  the  "To  Forever"  loopl.  The  result  of  the 
Advance  is  to  start  the  execution  of  process  A2.  After  the 
call  to  Advance,  process  Al  will  loop  back  to  the  call  to 
Await  with  an  awaited  value  of  1  this  time  and  (if  process 
A3  has  not  vet  advanced  ENFA3)  will  wait  there. 

Process  A2  is  programmed  as  shown  in  Figure  15. 
Note  that  it  first  calls  Await  with  the  eventcount  2NLA1  and 
an  awaited  value  of  1.  This  is  in  contrast  to  the  awaited 
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PROGRAM  MODULE  Ai:  DO; 

/*  Declare  Eventcounts  */ 

DECLARE  ENDA1 (6  )  BYTE  LATA  ( 'ENDA1%  ' )  i 
DECLARE  ENDA3 ( 6  )  BYTE  DATA  ( 'ENDA3%  ' ) » 

/*  Declare  a  local  word  variable  */ 

DECLARE  A1$AGAIN  WORD? 

/*  Declare  Synchronization  Primitives  */ 
CREATEtEVC:  PROCEDURE( EVENTCOUNT  )  EXTERNAL  ? 

DECLARE  EVENTCOUNT  POINTER? 

END? 

AtfAIT:  PROCEDURE(EVENTCOUNT,  VALUE )  EXTERNAL? 
DECLARE  EVENTCOUNT  POINTER, 
value  vord; 

end; 

ADVANCE:  PROCEDURE(EVENTCOUNT)  EXTERNAL? 
DECLARE  EVENTCOUNT  POINTER; 

END? 


/*  Pegin  Mainline  */ 

Alt  AGAIN  =  e;  /#  To  start  execution  immediately  */ 
CALL  CF.FATEtEVC ( GEN DAI 1  ;  /* 

CALL  CREAT2$EVC«*ENVA3); 

DO  WHILE  1?  /*  Do  Porever  */ 

/*  Check  to  see  if  processing  should  begin  */ 
CAIL  AtfAIT(OENDA3,Alt4GAIN)? 


/*  Processing  completed  so  notify  process  A2  */ 
CALL  ADVANCE(0ENDA1 ) ? 

/*  Increment  the  value  to  await  */ 

Alt AGAIN  =  Al t AGAIN  +  1? 

END?  /#  Of  Do  Forever  */ 

END?  /♦  Module  */ 


EXAMPLE  CODE  FOR  PROGRAM  Al 
Figure  IE 
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PROSHA!*  'MODULE  A2:  DO? 


/*  Declare  Eventcounts  */ 

DECIARS  3 NDA1 ( 6  )  FYTE  EATA  ('ENDA1%'); 

DECLARE  ENDA2 (6  )  BYTE  DATA  (  'ENDA2%  ' ) » 

/*  Declare  a  local  word  variable  */ 

DECIARS  A2$AGA IN  WORD? 

/*  Declare  Synchronization  Primitives  */ 
CREATSiSVC:  PROCSDURS(EVENTCOUNT )  EXTERNAL » 
DECLARE  EVENTCOUNT  POINTER? 

end; 

AWAIT:  PROCEDURE (EVENTCOUNT .VALUE )  EXTERNAL; 
DECLARE  EVENTCOUNT  POINTER, 

VALUE  WORD? 

end; 

ADVANCE:  PROCEDURE (E7ENT COUNT )  EXTERNAL; 

DECLARE  EVENTCOUNT  POINTER? 

end; 

/*  Pe^in  Mainline  */ 

A2$ AGAIN  =  i;  /*  To  start  execution  after  pro 
CALL  CREATE $E7C (0ENDA1 ) >  /* 

CALL  CFFATE^EVC (PENDA2) ? 

DO  WHILE  I?  /*  Do  Forever  */ 

/*  Check  to  see  if  processing  should  bemin  */ 
CALI  AWAIT (OENDAl , A2$AGAI N  )  ? 


/*  Processing  completed  so  notify  process  A3 
CALL  AD7ANCE(0ENDA2 )  ? 

/*  Increment  the  value  to  await  */ 

A2AAGAIN  =  A24AGAIN  +  1? 

END?  /*  Cf  Do  Forever  #/ 

END?  /*  Module  */ 


EXAMPLE  CODE  FOR  PROGRAY  A2 
Figure  19 
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PROGRAM  M0DTJLE  A3:  DC? 

/*  Declare  Eventcounts  */ 

DECLARE  FNDA2(6)  BYTE  DATA  ('ENDA2%')? 
DECLARE  ENDA3(6)  3YTS  DATA  ('ENDA3%')? 

/*  Declare  a  local  word  variable  */ 

DECLARE  A3$AGA  IN  WORD; 

/*  Declare  Synchronization  Primitives 
CREATE$FVC:  PROCEDUPE( EVENTCOUNT  )  EXTERNAL  > 
DECLARE  EVENTCOUNT  POINTER; 

end; 

AWAIT :  PROCEDURE (EVENTCOUNT , VALUE )  EXTERNAL; 
DECLARE  EVENTCOUNT  POINTER, 

VALUE  word; 

end; 

ADVANCE:  PROCEDURE (EVENTCOUNT )  EXTERNAL; 
DECLARE  EVENTCOUNT  POINTER? 

end; 


/*  Ppgin  Mainline  */ 

A3$AGAIN  =  1?  /*  To  start  execution  after  process  A2 
CALI  CREATESEVC (0ENDA2) ?  /* 

CALI  CREATEiEVC  (0ENDA.3)  J 

DC  WHILE  I?  /*  Do  Forever  */ 

/*  ChecV-  to  spe  if  processing  should  begin  */ 

CALL  AWAIT(0ENDA2,A3iAGAIN); 


/*  Processing  completed  so  notify  orocess  A1  */ 
CALL  ADVANCE (PEN DA? ) J 
/*  Increment  the  value  to  await  */ 

A3SAGAIN  =  A3 $ AGAIN  +  i; 

end;  /■■■  Cf  Do  Forever  */ 

END?  /*  Module  */ 


EXAMPLE  CODE  FOR  PROGRAM  A? 
Figure  20 
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va.lup  of  0  used  by  process  Al  in  its  initial  call  to  Await. 
Thus  process  A2  will  wait  at  this  point  until  signalled  Iv 
process  A1  (if  process  A2  begins  executing  before  process 
Al).  After  A1  performs  an  Advance  on  eventcount  ENLA1,  A2 
will  perform  its  processing  and  when  complete  will  signal 
process  A?  to  begin  via  an  Advance  operation  on  the 
eventcount  ENE-A3.  As  with  process  Al,  it  will  then  loop  back 
to  the  Await  operation  and  will  be  suspended  until  Al  once 
again  signals  it  to  continue. 

Figure  20  shows  the  program  for  process  A3. 
Frocess  A3  performs  an  initial  Await  as  the  others  did  and 
whpn  its  processing  task  has  been  completed,  it  signals 
process  Al  to  begin  the  "loop"  again  via  an  Advance 
operation  on  eventcount  FNTA3. 

These  three  processes  are  intended  to 
demonstrate  the  mechanics  of  synchronizing  with  eventcounts. 
As  can  be  seen,  the  operations  used  in  ail  three  of  the 
processes  are  very  similar.  The  real  differences  li°  only  in 
the  specific  eventcounts  that  each  process  uses  in  the  calls 
to  Await  and  Advance.  Note,  however  that  each  process 
performs  the  Await  operation  at  a  point  that  ensures  the 
process  will  be  synchronized  with  its  companion  processes 
even  if  the  process  begins  'out  of  order".  This  is  required 
to  avoid  confusion  since  there  is  no  guarantee  that  the 
first  of  the  three  processes  to  begin  executing  will  be  the 


one  intended  by  the  programmer  tc  execute  first  fviz.,  A!  in 
this  example ) . 

b.  Parallel  Processing  Pxample 

Suppose  that  instead  of  ine  sirrple  sequential 
execution  of  processes,  as  in  the  above  example,  one  wishes 
to  execute  processes  in  parallel.  The  eventcount  mechanism 
provides  the  capability  to  synchronize  parallel  processes  in 
(mechanically)  the  same  way  that  sequential  processing  is 
a  ccompl i shed . 

Consider  amain  the  three  processes  A1 ,  A2,  and 
A3  from  the  previous  example.  This  time  the  p r og rammer  notes 
that  processes  A2  and  A3  both  depend  on  input  data  (a  set  of 
filter  coefficients,  for  example)  from  process  A1  .  However, 
he  also  notes  that  neither  process  A2  nor  A3  alters  the 
input  data  (they  only  read  it).  Thus  processes  A2  and  A3 
become  candidates  for  parallel  execution  since  they  both 
have  a  common  event  upon  which  to  bertin  execution  (the  point 
where  the  input  data  becomes  available'  and  they  do  not 
depend  on  each  other.  Note,  however,  they  must  reside  ir. 
different  microcomputers  for  their  execution  to  actually 
occur  in  parallel. 

The  desired  flow  of  execution  is  shewn  in  figure 
21.  Implementing  the  parallel  execution  of  processes  A2  and 
A3  is  actually  a  simple  task.  Only  process  A3  need  be 
changed  .  Processes  A2  and  A3  await  the  seme  value  of  a 
common  eventcount  rather  than  different  ones,  "‘hus  the 
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PROGRAM  MODULE  A3:  TO? 

/*  Declare  eventcounts  <•/ 

/*  Eventcounts  ENDA1,  ENT A?  and  ENT  A3  */ 

/*  Declare  a  local  word  variable  #/ 

DECLARE  A3  $  AG  A I N  WORD? 

DECLARE  ENDAl(e)  BYTE  DATA  ('ENEAlV)J 
DECLARE  ENDA2 (6)  EYTE  DATA  ('ENDA2%'); 

DECLARE  ENDA3 ( 6  )  BYTE  DATA  ('ENDA3*'); 

/*  Declare  synchronization  primitives  #/ 

/*  Advance  and  Await  */ 

/*  Be^in  Mainline  */ 

/*  Create  the  eventcounts  */ 

A3$ AGAIN  =  i; 

DO  WHILE  lj  /#  Do  forever  */ 

CALL  AVAlT(r-ENDAl  f A3$AGAIN?  J 

/*  Perform  processing  */ 

/:;<  Processing  of  both  A2  and  A3  complete 
CALL  AWAIT(0EN'DA2,A3$AGAItn  J 
CALL  AD VANCE ( 0ENDA3 ) ! 

/*  Increment  the  value  to  await  */ 

A3$ AGAIN  =  A3i AGAIN  +  1? 

END;  /*  Of  Do  Ecrever  */ 

END?  /*  Of  Module  */ 


FARALLEL  PROCESSING  EEA^PLE  PROCESS  A 
Figure  22 


result  c •'  a  sir  t;  1  e  A d  v  a  r  o  e  or.  the  eventccun  t  *111  '  e  tc 

s i mul  t.a reu us  1  v  signal  processes  A?  and  A3. 

The  operations  performed  tv  process  A3  is  shown 
ir  Figure  22.  Process  Ai  is  still  required  to  perfcrr  its 


processing  first  to  provide  input  data  for  processes  A2  and 
.A3.  Thus  process  Al  perfcrps  an  initial  Await  operation  cn 
the  event  count  ZNTA3  with  an  awaited  value  of  2,  and  since 
the  eventoount  is  initialized  to  a  value  off  upon  creation. 
A 1  will  b-3  a  1 1  owed  to  continue.  Processes  A2  and  Ac  tc  th 
perform  their  initial  Await  operations  on  the  eventoount 
7M5A1  us  in#:  the  same  awaited  value  (they  each  wish,  tc  be^ir. 
processing'  when  the  set  of  input  data  becomes  available'. 
However,  process  A3  will  advance  the  value  of  ?\'?A3  or. ly 
aft^r  both  A2  and  A3  have  completed.  This  allows  Al  tc  wait 
for  the  ♦  v«  events  to  occur  (vi:.,  the  o-'-r  pie  tier,  of 
processes  A2  ar.i  Ac)  before  it  begins  neair..  Thus  »itb  the 
sincl?  Advance  operation  performed  b'1  Al  on  HnTai  two 
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PEOGf-Ai11  N‘CrriP  PRINTER  PROCESS  :  DC  ; 


/*  Declare  eventcounts  F'JLIB  and  EV?7Y,  used  */ 
/*  h  all  of  the  Drocesse^  *  ■' 

DECLARE  FULIF(c)  BYTE  DATA  (  'F’JLIB^')  : 

DECLARE  ”V?TY ( 6 )  PI TE  DATA  (  'EN'FTY%  ' ) * 

/*  Declare  a  local  word  variable  */ 

DECLARE  AGAIN  WORD; 

/*  Declare  synchronization  primitive^  */ 

/*  Advance  and  Await  * / 

/*  Fef'in  mainline  */ 

/*  Create  the  eventcounts  */ 

DO  WHILE  t;  /*  To  forever  */ 

CALL  AWAIT  (PFTJLI  E  ,  AGAI  N  )  ; 

/*  Perform  processing  */ 

/-  Processing  complete,  notify  others  */ 
/*  that  tuffer  is  availatle  *  / 

CALL  AD7ANCF(0EN-?TI)  5 

/*  Increment  the  value  to  await  *  ’ 

AGAIN  =  AGAIN  -  1J 

END;  /*  Of  Do  Forever  "V 

END:  /*  Of  vodu  1  e 
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PROGRAM  MODULES  A1  TFROUGH  Ak:  DO? 


/*  Declare  eventcounts  FULLE  and  a  sequencer 
/#  used  by  all  of  the  processes.  Sequencer 
/*  by  all  of  the  processes.  Sequencer  Is 
DECLARE  FDILB(6)  BYTE  TATA  ( 'FULLER  )j 
DECLARE  EMPTY (6 )  BYTE  DATA  aKPTTJ  )» 
DECLARE  TURNA (6)  ETTE  DATA  (  TURNA%  )* 


*/ 

*/ 

*/ 


/*  Declare  some  local  variables  among  which  is  T  */ 
DECLARE  T  WORD  5 


/*  Declare  synchroni2ation  primitives 
/*  Advance  and  Await  as  before  plus  Ticket 
TICKET:  ®ROCEDCRE(SEOUFNCER)  WORD  EXTERNAL; 
DECLARE  SEQUENCER  POINTER? 


*  / 
*/ 


end; 


/*  Begin  Mainline  */ 


/*  At  this  'point  process  needs  to  print  data  *•/ 
/*  so  create  the  eventcounts  as  usual  and  create  / 

/*  the  sequencer  'f 

CALL  CRFATE$SFQ(0TUPNA) ? 

/*  Obtain  a  "turn"  for  the  buffer  #/ 

t  *  ticket (otu? na) ; 

/*  Wait  for  "turn"  to  come  up  * 

CALL  AWAIT  ((? EMPTY »T)  J 

/*  When  awakened,  process  may  use  the  */ 

/*  buffer  (its  "turn  has  come  up)  */ 

/*  Finished  with  the  buffer  so  notify  */ 

/*  Printer  Process  that  there  is  output  */ 

CALI  ADVANCE (0FULIP) » 

END?  /♦  Of  Module  */ 


PROCESSES  A1  -  Ak  FOR  MUTUAL  EXCLUSION  FXAVPLE 

Figure  25 
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Sequencers  are  used  in  conjunction  with  eventcounts  to  solve 
these  types  of  problems. 


To  illustrate  mutual  exclusion,  consider  the 
flow  of  control  in  Figure  23.  Here  an  unknown  number  of 
processes  (A1  through  Ak)  require  access  to  a  single 
resource  (use!  by  A3).  Frinter  Process  is  some  printer 
service  and  the  single  shared  resource  is  its  input  buffer. 
Obviously  only  one  of  the  processes  requesting  printer 
services  can  be  allowed  to  write  into  the  input  buffer  at  a 
time  and  no  process  can  write  into  the  buffer  while  Frinter 
Process  is  trying  to  transfer  the  information  to  the 
printer. 

The  solution  is  shown  in  Figures  24  and  25. 
Figure  24  shows  the  programming  of  Printer  Process  and 
Figure  25  shows  how  each  of  the  processes  requiring  printer 
services  are  programmed. 

In  Figure  16,  Printer  Process  only  requires  the 
use  of  eventcounts  (since  it  does  not  alter  the  data  in  the 
input  buffer).  It  only  needs  to  know  when  to  begin 
transferring  the  data  and  to  signal  that  the  buffer  is  free 
upon  completion  of  the  transfer.  Thus  Frinter  Process  only 
uses  two  eventcounts,  FULL  and  FMPTT  corresponding  to  the 
buffer's  containing  data  from  a  process  ( FULI ^  and  its  being 
emptied  by  Printer  Process  (FMFTI).  Thus  Frinter  Fro-'ess 
performs  an  Await  operation  on  FULL  and  waits  for  an  input 
process  to  give  it  some  data.  When  a  process  performs  an 


Advance  or.  FULL,  Printer  Process  will  be  awakened  to  output 
it.  When  Printer  Process  finishes  outputting  the  data,  it 
will  perform  an  Advance  on  the  eventcount  EMPTY  and  loop 
tack  to  the  AWAIT. 

The  other  processes.  Figure  25,  are  to  use  the 
same  eventcounts,  performing  Awaits  on  the  eventcourts  EMPTY 
(waiting  for  the  buffer  to  become  available)  and  FUII 
(signalling  Printer  Process  that  there  is  data  to  print 
out).  Fowever,  the  awaited  value  is  derived  from  a  TICKET 
operation  on  the  sequencer  TURN.  Note  that,  each  cf  these 
processes  will  perform  TICKET  operations  on  the  same 
sequencer  (TURN)  and  so  will  all  receive'  unique  awaited 
values  ("turns",  as  in  taking  a  number  from  a  ticket  machine 
at  a  department  store,  [13])  for  the  buffer.  These  TICKET 
operations  will  return  a  unique  value  for  the  sequencer 
every  time  it  is  called  irrespective  of  which  process  calls 
TICKET  (provided  the  same  sequencer  is  used  as  the 
argument).  Then  the  processes  simply  wait  for  their  "turns" 
to  come  up.  Since  each  process  will  wait  fcr  its  "turn", 
there  will  only  be  one  process  writing  into  the  buffer  at  a 
time. 

This  example  demonstrates  the  use  of  sequencers 
in  mutual  exclusion  problems.  As  can  be  seen,  the  use  of 
sequencers  provides  a  very  simple  way  to  mediate  access  to 
shared  resources,  particularly  useful  when  the  number  of 
processes  involved  is  not  known  in  advance  or  may  change. 


D.  THE  OPERATING  SYSTEM  GATE 

Somehow  there  must  exist  a  linkage  between  the  user 
processes  and  the  operating  system  to  use  the  functions 
outlined  in  the  preceeding  paragraphs.  This  is  provided  by 
linking  to  each  user  process  one  operating  system  module 
known  as  a  GATE.  The  GATE  contains  the  Public  declarations 
for  the  synchronization  procedures  which  the  user  may 
access.  The  GATE,  then,  allows  the  user  to  call  operating 
syst  em  procedures  in  exactly  the  same  way  that  any  EXTERNAL 
procedure  would  be  called.  The  advantage  is  that  only  the 
GATE  (which  is  very  small)  must  be  linked  and  loaded  with 
each  user  process,  not  the  entire  operating  system. 
Additionally,  during  system  generation  [16]  ,  the  Gate  is 
located  (PL/M  terminology  for  the  assignment  of  absolute 
addresses)  in  exactly  the  same  place  in  memory  for  all  of 
the  processes.  The  result  is  that  the  Gate  segments  loaded 
ir  with  each  process  will  be  overlayed.  Thus  all  of  the 
processes  on  a  single  microcomputer  will  share  the  same  copy 
of  the  Gate  code.  This  minimizes  the  amount  of  physical 
memory  used  by  the  Gate. 

Figure  26  tabulates  the  required  format  for  all  of  the 
external  procedure  declarations  that  must  be  included  in 
each  user  module  making  use  of  operating  system  functions. 
Note  that  only  the  functions  actually  used  need  to  be 
declared . 
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Creating  an  Eventcount: 


CREATE$EVC:  PROCEDUPE(EVENTCOUNT )  EXTERN AI ? 

DECLARE  EVENTCOUNT  POINTER? 

END? 

Creating  a  Sequencer: 

CREATE$SEO :  PROCEDURE(SEQUENCER )  EXTERNAL? 

DECLARE  SEQUENCER  POINTER? 

END? 

The  Advance  Operation: 

ADVANCE:  PROCEDnRE(EVENTCOUNT)  EXTERNAL? 

DECLARE  EVENTCOUNT  FOINTER? 

END? 

The  Await  Operation: 

AWAIT:  PROCEDURE* EVENTCOUNT, VAL^E)  EXTERNAL? 
DECLARE  EVENTCOUNT  FOINTER, 

VALUE  WORD? 

END? 

The  Ticket  Operation: 

TICKET:  PROCEDURE (SEQUENCER )  BITE  EXTERNAL? 
DECLARE  SEQUENCER  POINTER? 

END? 

The  Read  Operation: 

READ:  PROCEDURE (EVENTCOUNT )  BITE  EXTERN AI? 
DECLARE  EVENTCOUNT  POINTER? 

END? 


KERNEL  CALL  EXTERNAL  PROCEDURE  DECLARATIONS 

Eigure  26 
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E.  SHARED  PROGRAM  CODE 


Processes  can  be  made  to  share  code  as  long  as  they  are 
all  loaded  on  the  same  microcomputer  and  the  shared  modules 
all  have  the  'REENTRANT'  attribute.  This  places  all  variable 
storage  on  the  stack  so  that  there  is  no  confusion  when  two 
processes  try  to  invoke  the  module  at  the  same  time. 

Because  the  system  is  bus-oriented  (all  of  the 
microcomputers  share  a  single  system  tusK  cede  sharing 
should  not  usually  be  forced  for  processes  which  reside  in 
different  microcomputers.  This  requires  access  to  the  system 
bus  for  instruction  fetches  making  this  technique  less 
efficient.  Therefore,  global  sharing  of  code  is  not  not  the 
expected  convention  during  system  generation,  although  it  is 
not  prevented  outright  [16].  In  fact  the  programmer  will  not 
he  in  direct  command  as  the  system  generation  operator  will 
make  this  decision. 

Cne  rule  of  thumb  that  quite  often  applies  to  attempts 
at  optimization  is  that  the  memory  that  is  saved  is  paid  for 
with  a  loss  of  speed.  Quite  often  one  can  speed  execution  up 
drastically  if  he  is  cot  overly  concerned  about  using 
memory. 

In  summary,  the  sharing  of  code  segments  to  save  memory 
is  a  technique  that  is  discouraged  in  this  system  if  the 
processes  which  share  them  reside  on  different 
microcomputers.  It  will  "work",  of  course,  but  has  a  very 


detrimental  effect  on  performance 


F.  SHARED  TATA 


Sharing  of  data  between  processes  is  tightly-coupled  in 
that  the  data  is  not  explicitly  transmitted  from  one  process 
to  another.  Pather,  data  sharing  is  accomplished  by  usin g 
shared  PI/M  data  segments.  These  shared  data  segments  can 
reside  in  global  memory  where  they  are  directly  accessible 
to  the  processes  concerned. 

PL/M  allows  one  to  develop  programs  modularly  by 
providing  data  declarations  with  FOEIIC  and  EXTERNAL 
attributes.  When  the  modules  are  linked,  all  of  the  declared 
variables  (such  as  byte,  word  and  pointer  quantities, 
arrays,  structures,  etc.)  are  collected  into  a  single  data 
segment  for  the  program.  Thus  PI/M-S6  expects  that  each 
program  will  have  its  own  local  data  segment. 

In  modules  where  a  variable  is  declared  with  the 
EXTERNAL  attribute,  it  is  understood  that  the  variable  may 
actually  reside  in  a  non-local  data  segment.  The  intention 
is  that  eventually,  when  all  of  these  modules  are  linked 
together  into  one  program  the  P’JELIC  and  EXTERNAL  references 
will  be  resolved. 

Processes,  though  are  not  linked  together.  They  are 
altogether  independent  PI/M  programs.  However,  one  can  share 
data  in  much  the  same  way  as  the  modules  in  a  single  r L/K 
program  by  declaring  all  shared  data  in  the  processes  with 
the  EXTERNAL  attribute.  Thus  each  process  will  be  aware  of 
the  existence  of  a  separate  data  segment.  The  shared  data 


segment  is  then  separately  created  as  a  FI/M  module 
containing  only  shared  data  declared  with  the  FUFIIC 
attribute  —  no  local  data  or  code  is  ever  included.  This 
module  is  then  compiled  separately  and  linked  to  each  cf  the 
processes  sharing  the  data  as  if  it  were  simply  another 
program  module.  The  only  difference  is  that  this  module  will 
only  have  a  meaningful  data  segment.  The  code  segment  will 
be  empty. 

It  must  be  emphasized  that  such  data  segments  are  the 
only  means  of  communication  between  processes.  In 
particular,  a  reference  to  an  absolute  address  (including 
constant  or  computed  pointer  values)  is  NEVER  allowed.  To  do 
so  will  destroy  the  integrity  of  this  operating  system 
design. 

G.  FRIVI13GED  INSTRUCTIONS 

Because  the  operating  system  controls  the  physical 
resources  of  the  system,  certain  instructions  which  are 
valid  in  either  the  high  level  language  FI/M  or  the  6££6 
assembly  language  ASM-86  may  not  be  used.  The  reason  for 
this  is  that  their  use  will  interfere  with  the  correct 
operation  of  the  system. 

1.  Interrupt  Masking 

The  operating  system  uses  the  interrupt  structure  of 
the  system  for  its  own  purposes.  Because  of  this,  the  user 
must  never,  repeat  NSVEP,  mask  interrupts  using  the  assembly 
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language  CLI/STI  instructions  or  the  PI/M-66  IISA BIE/3NAEIE 
instructions . 

The  operating  system  uses  interrupts  system-wide 
during  normal  operation  and  requires  that  interrupts  he 
unmasked  at  all  times  while  user  processes  are  executing. 

This  is  not  to  he  confused  with  the  use  of  interrupt 
handler  routines  which  are  required  for  certain  software 
packages,  notably  the  PI/M-66  real  number  library  routines. 
These  will  not  interfere  with  system  operation. 

2.  Input/Gutput  Operations 

Direct  access  to  Input /Output  facilities  is  also 
the  purview  of  the  operating  system.  Thus  the  user  is  also 
prohibited  from  using  the  PI/M  and  ASM-96  I/O  instructions. 
Instead,  a  system  service  is  provided  to  perform  I/O 
functions  for  the  user. 
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APPENDIX  B  -  KERNEL  MODULES 


This  section  contains  the  detail  "pseudo-code 
for  the  kernel  modules.  These  have  not  been 
fully  tested  and  should  only  he  considered  an 
aid  to  understanding  and  not  final  code. 
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/*  TEE  INNER  TRAFFIC  CONTROLLER  */ 
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/*  VIRTUAL  PROCESSOR  SCHEDULER  */ 

/Jjt#*!}!**^**#****#*#**###*##^#*^*^*#****#***#*#####^*^#****#/ 

♦  External  FL/M-S6  procedures  called  hy  this  module 


E7TRN  GETVOFK: 

FAR , 

RUNTHISVP: 

FAR, 

RDYTHISVP: 

FAR, 

LOCEVPM : 

far, 

UNLOCKVPM: 

FAR 

SCHEDULER  SEGMENT 

PUBLIC  VPSCHSDULEP. 

VFSCREDULER  PROC  FAR 

ASSUME  CS:SCEEDULER 
ASSUME  DS : NOTEI NG 
ASSUME  SS : NOTHING 
ASSUME  ESjNOTHING 

»  Entry  point  for  a  call  to  VpScheduler 
;  Establish  activation  record,  save  registers  that 
i  VpScheduler  will  use. 

PUSH  DS 
vUSH  AX 
PUSH  CX 
PUSH  P? 

CALL  L0CE7PM 
CALL  RUTHISV? 

MOV  B?,S? 


MOV  CX,0R 


;  0H  Indicates  normal  return 


Entry  point  for  a  preempt  interrupt.  Reached  by  a  jump 
from  ITC_?RSEMPT_EANDLER  procedure. 

INT  ENTRY:  PUSH  Cl 

CALL  GET'iORK  5  Returns  new  "MR*  in  the 
»  AX  register 

POF  CX 

Swap  virtual  processors.  This  is  accomplished  by  savin? 
the  SP  and  EP  registers  in  known  locations  at  the  base 
of  the  stack  along  with  the  VpScheduler  return  type 
flag.  The  process  hound  to  the  selected  virtual 
is  accessible  via  the  address  space  descriptor, 
the  SS  register  value. 

MOV  SS : WORD  PTR  e.SP 
MOV  SS : WORE  PTR  2,3F 

MOV  SSjWORD  PTR  4,CX  >  Return  type  flag 

MOV  SS,AX  >  New  address  space  desc. 

Swap  is  complete  at  this  point  since  the  SS  register 
now  holds  the  new  stack  segment  value 

MOV  SP,SS:VORD  FTR  0 
MOV  BP, SS: WORD  PTR  2 
PUSH  AX 

CALL  RUNTHISVP 
MOV  CX , SS : WORD  PTR  4 

Check  VpScheduler  return  type  flag  to  determine  the  type 
of  return  required  for  the  process. 

CMP  CX,77F  ;  Return  type  flat  =  Interrupt? 

JNE  N0FM_RET  ;  If  not,  do  a  normal  return 

JMP  INT  RET  J  If  so,  do  an  interrupt  return 

NORM  RET:  CALI  UNLOCKVPM 

POF  BP 

POP  CX 

POP  AX 

POF  DS 

RET 

VPSCHEDULER  ENDP 
I TC_PREEMFT_P ANTLER  FROC  FAR 

ASSUME  CS  SCHEDULER 
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ASSUME  IS :NOTHING 
ASSUME  SS  jNOTHIN'G 
ASSUME  ES: NOTHING 


INT_VEC :  CLI 
PUSH  ES 
PUSH  IS 
PUSH  AX 
PUSH  CX 
PUSH  EX 
PUSH  IX 
PUSH  SI 
FUSE  II 
CALI  LOCXVPM 
CALL  RITTHISVP 
JMF  INT  ENTRY 
I  NT  RET:  CALL  UNIOCKVPM 

CALL  CHECXPREEMPT 

POF  II 

POP  SI 

POP  BX 

POP  IX 

POP  CX 

POP  AX 

FOP  IS 

POP  ES 

IRET 

itc_presmft_eamler  ENEF 
SCEEIUIER  ENTS 


####»!«  Jfss;«  a!:##  s',s 

/*  Virtual  Processor  Scheduler  Internal 


Modules  */ 

»:t  s:t  *Jc  s>;  *;r  *:i  »  / 


/*  Externally  lefined  Variable  leclarations 


*/ 


EECLARE  VFM(l)  structure 

( VP$STATE  EYTE, 
VP$PRIORITT  BYTE, 
EVCAAW?IE  BYTE, 
E VC $ AW $ VALUE  WORE, 
SS$REG  WORE, 
FEiPENE  BYTE) 


EXTERNAL? 


EECLAPE  V?M$LCCK  EYTE  EXTERNAL 


DECLARE( CPU$ NUMBER , VP $S TART, VP£ END , VPS  £ PER $ CPU ' 
3TTE  EXTERNAL? 

DECLARE  IDLEiDBR  WORD  EXTERNAL; 

DECLARE  CPU$XNTiVECT0R(l6)  BYTE  EXTERNAL; 

/#  Literal  constants 

DECLARE  FALSE  LITERALLY  '0', 

READY  LITERALLY  'l'f 
? TINNING  LITERALLY  '3', 

WAITING  LITERALLY  '7', 

IDLE  LITERALLY  '15', 

TRUE  LITERALLY  '113'; 

/*  External  Procedure  Declarations 

TC$PE$HANDLER:  PROCEDURE  EXTERNAL? 

end; 


/*  GETWORK  Procedure  */ 

/*  Function  call.  Searches  the  Virtual  Processor  i“ap  */ 

/*  the  highest  priority  runnable  virtual  processor  */ 

/*  (state  is  either  reaDy  or  idle  with  the  Preempt  */ 

/*  Pending  Flag  set).  Returns  the  D3R  value  (SS  */ 

/*  Register  value)  of  the  bound  process  in  the  Ax  */ 

/*  Register.  V 

GETVCRY:  PROCEDURE  VCRD  REENTRANT  PUBLIC  * 

DECLARE  (PPI,I)  BYTE? 

DECLARE  SELECTED$DBR  WORD? 

/*  Beeln  search  of  the  Virtual  Processor  Map  usine  the  */ 
/*  priorities.  Initially  set  to  the  lowest  possible.  *V 
PRI  =  255? 

DO  /*  Search  Virtual  Processor  Map  for  the  highest  */ 

/*  priority  ready  virtual  processor  to  run.  */ 

I  =  VPiSTART  TO  VP i END» 

IF  /*  The  virtual  processor  can  be  selected,  it  is  #/ 
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*/ 

*/ 


/*  is  either  the  ready  state,  or  the  idle  state 
/#  with  a  virtual  preempt  pending. 

((VFM(I). VPS PRIORITY  <  FRI)  AND 
(VFM(I).VFSSTATE  =  READY  OR 
(VPM( I) .V?$STATE  =  IDLE  AND 
7PM (I  ).PESPEND  =  TRUE)))  THEN 

DO?  /*  Select  the  virtual  processor.  */ 

SELECTED$DBR  =  VFM ( I ) .SS $REG ; 

PRI  =  7FM(I) .VPSPRIORITY; 

END?  /*  Do.  Select  the  virtual  processor.  #/ 

END?  /*  DO  loop  search  of  the  7irtual  Processor  Map.  */ 

/*  Return  the  SSSREG  value  of  the  selected  virtual  */ 

/*  processor  in  the  AX  (Accumulator)  Register. 

RETURN  SELECTEB$DBR? 

end;  /*  GETWORX  Procedure.  */ 


/* 

RUNTHISVP 

Procedure 

*/ 
_ £t  / 

/* 

/* 

/* 

Sets  the 
Searches 
process  's 

selected  virtual  processor  to  running, 
the  Virtual  Processor  Map  with  the 
SEI?CTED$DBR. 

— '  / 
*/ 
#/ 
*/ 

/:}( #s)cJ!r  jf:#  j)t  #j(c  :Jc  >jt  :Js  >*!  / 


RUNTRIS7P :  PROCEDURE (VFSDRR)  REENTRANT  PUBLIC; 
DECI ARE  VP $DER  *CRD, 

vp  byte; 


VF  =  VFSSND  J 

DC  VEILS  /*  Look  for  the  7P  with  this  SS$EEG  value.  */ 
(7?M(VF) .SS$REG  <>  7P$DBR); 

7P  =  VF  -  1; 

END;  /*  Do  While  */ 

7FM(7P).VP$STATE  =  RUNNING? 

RETURN  J 

FND?  /*  RUNTHIS7F  Procedure.  */ 

tfJjcijfJjt  #£##>}(  A**  fcsfr  / 

/*  RDYTEISV?  Frocedure  */ 


A - */ 

A  Sets  the  currently  running  virtual  processor's  #/ 

A  state  to  ready.  #/ 


RDYTKISVP :  PROCEDURE  REENTRANT  PUBLIC ; 

VpM(ITCiPET$VP) .VP t STATE  =  READY; 

return; 

EN’E;  A  RDYTHISVP  Procedure  */ 

*  #>!I  «#  *«*♦#***  «***«««*#  f 


A  LOCKVPM  Procedure  */ 

A  locks  the  Virtual  Processor  Map.  */ 


LOCKVFM :  PROCEDURE  REENTRANT  FUBLIC; 


A  pi/^-gfi  tuilt-in  spin-lock  procedure.  */ 

DO  WHILE  I0CXSST(<?VPM$L0CK#119J? 

ene; 


return; 

end;  A  LOCKVPM  procedure.  */ 


A  UNL0CS7PM  Procedure  */ 


A  Unlocks  the  Virtual  Processor  Map. 

/  >!«#*  ft##**#  !;«#<«  $$#  <«#*  $$««« 


*/ 


UNLOCKVP^ :  PROCFEURE  REENTRANT  FUIIIC; 


vpmUock  »  c; 
return; 

end;  A  UNEOCEVPM  Procedure.  */ 


/ft#*!*######*###  3ft s|:»^ »;i $  ft  $>;:$$  s,’!#  •' 


A  FEWFilNT  Procedure  */ 

A - */ 

A  Generates  a  hardware  preempt  interrupt.  V 


/ft*#*#***# # ##*.•## *#*#>!«$ / 

HDWRilNT:  PROCEDURE ( CFU )  REENTRANT  PUBLIC; 

EECLARE  CFU  BYTE, 


IIP 


FORTA  LITERALLY  '0CSH'; 

OUTPUT  (FORTA)  =  CPU$INT$72CT0R(CPU) » 

RETURN 

END;  /*  HDVESINT  Procedure.  */ 

$4$$$$  4444  4 44444444444444444  / 

/*  Inner  Traffic  Controller  Interface  Modules  */ 

/4**4***i{t4*>!«*>is#*sSsfc*#*s!c«*4>!s*>i«*#*:f:!!!sS<####*#>!<>S«*4#>ii*#*4*>!t*##4#*  f 


/4#«*4fc#*44***4##£>;-i:!*4#*«4*»::*:i$fc>!c*J(e**#>StsSt#*#«4#**>MtsMt*#4****  j 


/*  IBLE$VP  Procedure  */ 

/* - */ 

/*  Sets  the  state  of  the  virtual  processor  now  */ 

/*  running  to  idle,  binds  the  "idle  DBR”,  sets  a  */ 

/*  high  priority  and  calls  Vo  Scheduler.  */ 


4445444444444 444#$*** 4444444  / 

IDLEiVP:  PROCEDURE  REENTRANT  PU3IICJ 

DECLARE  VP$TO$IDIE  BYTE  * 

VPATOilDLE  *  ITC$RET$7P; 

V?M(VP$T0$IDLE).VP4STATE  *  IDLE? 
VPM(VP$70$IDLE).VP$PRI0RITY  =  10; 

VPM(VF$T0$IDLE).SS$REG  =  IBLE*DB?.; 

CALL  v*$ceebuler; 

return; 

end;  /*  IDIEAVP  Procedure.  */ 

/444444444444444 444444444444444444444444444444444444444444  ^ 


/*  ITCSLOADiVP  Procedure  */ 

/* - - - - - ♦/ 

/*  Performs  a  "Swap  Virtual  DB?" .  Binds  the  virtual  */ 

/*  processor  to  the  new  process,  updates  VPiFRIORITT  V 

/*  and  SS$REG,  and  sets  state  to  ready.  */ 


/444444  44444444444444444444  g*#  444444#4$*t4?1r>i(*!<!#)Cc4j*s>t$4444444  / 


ITC$IOAD$VP:  PROCEIURE(PRI$PARM,DRR$FARM)  REENTRANT  PUBLIC; 

DECLARE  PRI$PARM  BYTE, 

DBR$PARM  WORD, 

load$vp  byte; 
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/*  Identify  running  virtual  processor.  */ 
LOAD^YP  -  ITC$EET$7P; 


/*  Bind  the  virtual  processor.  */ 

7PM(L0AD$7P).7P$STATE  *  READY J 
7PM(IOAD4YP).7pi?R I OR  ITT  *  PRIiRARM? 

7PM ( LOAD $7P ) . SS  $R3G  -  DBR$PARMJ 

/*  Schedule  the  virtual  processor.  V 
CALL  YPSCFEDULERJ 

return; 

end;  /*  ITC$L0AD$7P  Procedure.  */ 

/ft*###*********#*##**##**###*##*#***##*#*#**##**###****###*/ 


/*  ITCiRST$7F  Procedure  */ 

/*  Function  call  which  returns  the  identity  of  the  */ 
/*  virtual  processor  which  is  new  running  on  the  */ 
/*  physical  processor.  */ 


ITC$RET$7F:  PROCEDURE  BITE  REENTRANT  PUBLIC,* 

/*  Search  through  the  set  of  virtual  processors  assigned  */ 
/*  to  the  phsyical  processor.  */ 

RUNNING$7?$ID  =  7P$ START; 

DO  WHILE  /*  Have  not  found  the  running  virtual  processor  */ 
(7P^(EuNNING$7P$ir) ,7p ESTATE  <>  RUNNING  1 ; 

/*  Search  next  entry.  */ 

HUNNINC$7P4ID  »  RUNN ING$7F$ID  ♦  l; 

END;  /*  While  loop  search  for  running  7P.  RUNNING$7F$ID  */ 


/*  points  to  the  running  virtual  processor.  */ 

/*  Return  the  identity  of  the  virtual  processor  */ 
/*  in  the  AX  (Accumulator)  Register  */ 

RETURN  P.UNNING$7P$ID; 

end;  /*  ITC$RST*7F  Procedure.  */ 

/  #*#  ##  *  ft  #  ft*  lie  ftft  ft  ft  ft  ftft  ft  ft  ft  ft  ft ft  ft  ft  ft  *  $  <i  $  ft  ftft  ftft  <i  ft  *  ft  *  *  ft  *  $  *  *  *  41  <1 41  ftft  <1 41  *  / 

/*  CFECKPREEMPT  Procedure  V 

/* - */ 
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/♦  Checks  for  a  virtual  preempt  pending.  If  there  */ 

/*  is  one,  calls  the  Traffic  Controller  Preempt  */ 

/*  Handler.  */ 

/****«##*$#*&>**#**$«*#*****##*  iCc*#****#*#**##********##**#*^/ 

CFECKPRSSMFT:  PROCEDURE  REENTRANT  PUBLIC? 

DECLARE  RUNNING$VP  BYTE? 

/*  Find  the  identity  of  the  running  virtual  processor  */ 
RTTNNI NG$  V?  *  ITC$RET$VP? 

DO  WHILE  /*  Preempt  Pending  Flag  of  the  virtual  */ 

/*  processor  is  on.  */ 

VPM(RUNN INGiVP ) .PE$PEND  *  TPUSJ 

/*  Reset  Freempt  Pending  Flam.  */ 

VPM(FUNNING$vp)  .PE$?END  =  FALSE? 

/*  and  call  Traffic  Controller  Preempt  Handler.  */ 
CALL  TC$PE$FANDLER? 

RUNN ING AVF  =  ITC$RZT$VF? 

END?  /*  While  loop  handling  of  the  virtual  preempt.  */ 

RETURN? 

END?  /*  CFEC^PREEMPT  Procedure.  */ 


#$#$$$$$  ft  (1^4111  ftftftftft ft  ft  ft ft  ft  ft ft  ft K> a;a 4c ]Q< X:  V / 


/*  IT C$SFND$ PREEMPT  Procedure  V 

/* - - - V 

/*  Issues  virtual  preempts  (preempt  interrupts  to  */ 

/*  virtual  processors)  ty  setting  the  appropriate  */ 

/*  Freempt  Pending  Flag  in  the  Virtual  Processor  Map  V 

/*  and  then  issuing  a  hardware  interrupt  if  the  */ 

/*  processor  is  on  a  different  physical  processor.  */ 


ITCiSENDiPRFEMPT:  PECCErURE(TGT^CFU,VPiID)  REENTRANT  PrillC? 

DECLARE  TGT*CPU  WORD, 

7FilD  WORD? 

/*  SET  THE  FP.E-SMPT  PENDING  FLAG  */ 

VFM ( TGT^CPU  *  VPS$FER$CPU  +  7P$ID )  .PE  >FEN’D  *  TRUE: 
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♦*!%>  ... 


IF  (TGT$CPU  O  CPU$NUMBSR)  THEN 
CALL  HDWR$INT(TGT$CPU); 

return; 

2nd;  /*  ITCiSSND*FREEMFT  Procedure.  */ 


/*  ITC$AWAIT  Procedure  V 

/* - */ 

/*  Eventcount  synchronization  mechanism  for  use  ty  the  V 

/*  Inner  Traffic  Controller  in  the  management  of  */ 

/*  system  resources.  */ 


iTCiAWAlT*  PROCEDURE ( EVC $ID , AW AITEDiV ALUS)  REENTRANT  PUBLIC? 
DECLARE  EVC$1B  RITE, 

AWAITED$7 AIUE  WORD, 

RUNNING$VP  BYTE, 

I  BYTE; 

/*  Lock  the  Virtual  Processor  Map  */ 

DO  WHILE  I0CXS2T(0YPM$L0CK,U9); 

end; 

DO; 

/*  Identify  the  running  virtual  processor  */ 

RUNNINGSVP  =  ITC42ET4VF? 

IF  SYS$E7CiTA2LE(EVC$ID)  <  AWAITED$ VALUE  THEN 

do; 

V?M(RUNN ING  $VP).VP$STAT2  *  WAITING? 

VPm(RUNN ING$VP) .EVC$AW£IB  =  EVC$ID? 
VPM(RUNNING$VP).SVC$AWiVALU3  =  AWAITEDSVALUEJ 

end; 

ELSE 

v?m(running$v?) .vpjstate  =  ready; 
end; 

/*  Schedule  the  virtual  processor.  */ 

CALL  VPSCPEDULER? 

/*  Unlock  the  Virtual  Processor  Map.  #/ 

vpmUocx  *  e; 
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return; 

END*  /*  ITCiAWAIT  Procedure.  */ 

/ 

/*  ITCiADVANCE  Procedure  */ 

/* - */ 

/it  Ever.tcount  signalling  mechanism.  Used  by  the  Inner  */ 

/*  Traffic  Controller  in  mana^in*  resources.  */ 


ITCiADVANCE:  PROCEDURE(EVC£lD )  REENTRANT  FUEIIC 
DECLARE  EV  C  £  I D  BYTE, 

I  byte; 

/*  Lock  the  Virtual  Processor  Map  */ 

DO  WHILE  LOCKS ET (P7Pk£lCCK,119)  * 
end; 


SYS £EVC£T ABLE (EVC^ID)  =  SYS $SVC ABLE (EVC£lD)  +  1J 

DO  I  =  (*  TO  (NRiVPS  -  1); 

IF  VPM(I).EVC$AWiID  «  EVC$ID  THEN 

IF  VPM ( I ) . EVC $AWi VALUE  <-  SYS $EV C£TAILE ( EV Ctl I )  THEN 
DO? 

VPM( I ) . VP^STATE  *  READY; 

VPM(I).EVC£AV£lt  =  255J 

vpm(i).evc£aw£value  =  e; 

IF  (I  <  VF£sTART)  OR  (I  >  VF  ?END )  THEN- 
CALL  kdvr£int(i /vpsiFERicFtn ; 

end; 

end; 

call  vpscfeduler; 

/♦  Unlock  the  Virtual  Processor  Map  */ 

VpMiLOCK  *  05 


RETUPN ; 

end;  /*  ITCiADVANCE  Procedure.  */ 


/*#**#***# ft*#*************************#*#*##*********#******/ 

/*  TRAFFIC  CONTROLLER  */ 

/***444>!t44*44i!«4*444J!«4*4«*444](«jj«4*4j}i>it44*i)i4445:«>Si«4s!i4444A44**»!c44i{c  / 


/* »!« >!<44  1(1  44  <5  44  4  4  4444  <1  44  <*  t>it  <1  tt  it  4  4  44  4  4  444  4  444  <1  4  4  444444  4  4  444  4 4 4  ^ 

/*  External  Global  Data  Declarations  */ 

/4 s«t>)e  >}t  44444444  ))t 44  4  4  4 44  444444  4  444  4  4  4  4  4  *  4444  444444  44  4  444  444  44  j 
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DECLARE  AFT(l)  STRUCTURE 


(STATS  BITS, 
AFFINITY  BYTE, 
V?$ID  BYTE, 
PRIORITY  BYTE, 
LOAD i THREAD  BYTE, 
EVC$VAIUE$AW  WORD, 

thread  byte. 


DBR 


WORD)  EXTERNAL? 


DECLARE  APT$IOCX  BYTE  EXTERNAL? 


DECLARE  PROCESSES  BVTE  EXTERNAL? 

DECLARE  LOAD$LIST ( 16 1  BYTE  EXTERNAL? 

DECLARE  EVC$TABLE(l)  STRUCTURE 
(EVC£NAMS(6)  BYTE, 

EVCSVALUF  WORD, 

APTtPTR  BYTE)  EXTERNAL? 

DECLARE  EVENTS  BYTE  FXTERNAI ? 


DECLARE  SE0$TA3LE(1 )  STRUCTURE 
(SEC>NAME(6)  BYTE, 

SSO$VALUF  WORE)  EXTERNAI ? 

DECLARE  SEQUENCERS  BYTE  EXTERNAL? 

DECLARE  (C?U$ NUMBER ,VP$START ,VFiENr ,V?S $?ER$CPU) 

RYTE  EXTERNAL? 

DECLARE  (NR$?HPS  ,NR$VPS)  BYTE  EXTERNAL? 

DECLARE  CPUiINT$7ECT0R( 16 )  BYTE  EXTERNAL? 

DECLARE  PFO$?ARAl^  STRUCTURE 


FLAGS 

WORD, 

CS 

WORD, 

IP 

WORD, 

ES 

WORD, 

DS 

WORD, 

A7 

WORD, 

CX 

WORD, 

rx 

WORD, 

BX 

WORD, 

SI 

WORD, 

El 

WORD, 
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?S  WORD, 

FRIORITY  BYTE, 

AFFINITY  BYTE}  EXTERNAL; 


/* 


Literal  Constant  Declarations 


*/ 


DECLARE 


FALSE 

READY 

RUNNING 

BLOCKED 

TRUE 

NOT$FOT7ND 

NIL 


LITERALLY 

LITERALLY 

LITERALLY 

LITERALLY 

LITERALLY 

LITERALLY 

LITERALLY 


'e\ 

'i\ 

'3', 

'7', 

'113', 

'255', 

'255'; 


/*  External  Procedure  Declarations  */ 

ITC$RET$VP:  PROCEDURE  BYTE  EXTERNAL;  , 

end; 


I?C$LOAt$VP: 


end; 


PROCEDURE (PRI $?ARM ,DBR$?ARfO  EXTERNAL? 
DECLARE  PRliPARM  BYTE, 

DBRaFARM  WORD? 


IDLSiVP:  PROCEDURE  EXTERNAL? 

end; 


ITC$SEND$PREEMPT: 


end; 


PRO  CEDURS ( TGT  $  CPU , VP  $  I D )  EXTERN AL  ? 
DECLARE  TGT$CPU  WORD , 

VF$ID  WORD; 


/*  IKE  PROCESS  SCHEDULER  */ 

/*#*«$#***  a*:***,*)*  #**>{(#  #***###*<!*********#****#:!:#*>}!**  / 


/*  TCSSCHEDULBR  Procedure  */ 

/* - */ 

/*  Process  scheduler.  Searches  for  the  highest  */ 

/*  priority  runnahle  process  to  load  onto  the  */ 

/■*  virtual  processor.  If  no  runnahle  process  is  */ 

/*  found,  will  idle  the  virtual  processor.  V 


TCiSCFEDULER :  PROCEDURE  REENTRANT  PUBLIC; 
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DECLARE  PROCESS  BYTE, 

SELECT$?P-OCESS  byte; 

PROCESS  =  LOAD$LIST(CPU$NU*BER) ; 

SEIECTiFROCESS  =  FALSE? 

/*  Search  down  Load^Iist  for  the  highest  priority  */ 

/*  ready  process  runnable  on  this  physical  processor.  */ 

DO  WHILE  /*  Have  not  found  a  runnable  process.  */ 

( S ELECT $P ROC  ESS  =  FALSE}? 

IF  /*  Haven't  reached  the  end  of  the  LoadiList  */ 

(PROCESS  <>  ML)  THEN 

DO?  /*  Check  process.  */ 

IF  /*  Process  is  ready.  */ 

(APT(PROCSSS). STATE  *  READY )  THEN 

/*  Select  the  process  to  run.  */ 

SELECT ^PROCESS  *  TRUE? 

ELSE 

Check  the  next  process.  V 
PROCESS  =  AFT (PROCESS )  .LOAE$THREAI? 

END?  /*  If  then  else.  */ 

END?  /*  While  loop  search  for  next  ready  process.  */ 

/ 

IF  /#  Have  found  a  ready  process  to  run.  */ 

( S ELEC T$ PRO CES S  =  TRUE)  THEN 

DO?  /*  Give  away  the  virtual  orocessor.  */ 

APT(PROCSSS ) .STATE  =  RUNNING? 

APT(PROCESS ) ,7P$ID  *  ITC$RET$VP? 

CALL  ITC i LOAD $VF (APT ( PROCESS ) .PR IOR IT Y , APT (PROCESS ) .DER) ? 
END?  /*  Give  away  the  virtual  processor.  */ 

ELSE 

/*  No  runnable  process  has  been  found  so  idle  the  */ 

/*  virtual  processor.  */ 

CALL  IDIEiVP? 

RETURN? 
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2ND;  /*  TCiSCHEDULER  Procedure.*/ 


/*  PROCESS  SCHEDULER  INTERNAL  MODULES  */ 

/«$«$##*49i:$ltc#43!e$«$:Cc$*$$#$>S':i'4$$:!:$*!:’t;>!:9i‘#>i»:‘4’S‘##$$$>:<<:#<:$4>::$#4::-.##3::  / 

/*  TC$LOCATE$EVC  Procedure.  */ 

/* - */ 

/*  Function  call.  Returns  the  identity  of  the  */ 

/*  eventcount  (the  index  of  the  eventcount  in  the  */ 

/*  Eventcount  Table)  in  the  AX  (Accumulator)  */ 

/*  Register.  Input  argument  is  a  pointer  tc  the  */ 

/*  byte  array  in  the  user  process  holding  the  name  */ 

/*  of  the  eventcount.  */ 


TC$LOCATE$EVC  :  PR0CEDURE(2$NAM2$PTR )  BYTE  REENTRANT  PUBLIC; 
DECLARE  E$NAME$PTR  FOINTER J 

declare  char  Rased  e$name$ftr  (5)  byte; 

DECLARE  I  BYTE, 

EV C$1 D  BYTE, 

MATCH  BYTE; 


i  =  i?; 
evc$id  -  ?; 

MATCH  =  FALSE; 

/*  Search  down  the  eventcount  table  to  locate  the  */ 
/*  desired  eventcount  by  matching  the  names  */ 

DO  ¥FILS  /*  haven't  found  the  eventcount  and  */ 

/*  haven't  reached  end  of  table  */ 
(MATCH  =  FALSE)  AND  (EVC$ID  <  EVENTS),* 

IF  /*  the  two  characters  match  */ 

( CHAR  (I )  =  EVC$TABLE(EVC$IE).E7C$NAME(D)  THEN 

DO;  /*  Check  for  end  of  strings  */ 

IF  /*  Reached  the  end  of  the  strings  */ 

CHAR (I)  =  TEEN 

/*  Fave  located  the  desired  eventcount  */ 
MATCH  =  TRUE; 
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W 1 


SIS  2 

A  look  at  the  next  character  */ 
i  =  i  +  1; 

END;  A  Check  for  end  of  strings  */ 

El  SE 

DO?  A  Ready  for  check  next  entry  */ 
i  =  e; 

Evc$ir  =  Evc$ir  ♦  1; 

END;  A  Ready  for  check  next  entry  <*/ 

END?  A  While  loop  search  for  desired  eventcount  */ 

I?  A  Pave  found  the  eventcount  */ 

(MATCH  =  TRUE)  THEN 

A  Return  its  index  in  the  EVCiTABIE  */ 

RETURN  EVC5IDJ 

ELSE 

A  Return  NOT^FOUND  error  code  */ 

RETURN  N OT$ FOUND ; 

end;  A  TCU0CAT3*EVC  Procedure.  */ 


A  TCUOCATE^SEQ  Procedure  */ 

A - */ 

A  Function  call.  Returns  the  index  in  the  */ 

A  sequencer  table  of  the  sequencer  name  * iven  #/ 

A  to  it.  Input  arguament  is  a  pointer  to  the  */ 

A  string  natre  of  the  sequencer  in  the  application  */ 

A  program.  */ 


TC$LOCATE'aSEC  :  PROCEDURE ( S  ?NAME$PTE )  BITE  REENTRANT  PUBLIC; 

DECLARE  S$NAM£$?7F  POINTER; 

DECLARE  CHAR  BASED  SiNAMEiFTE  (5)  BYTE; 
DECLARE  I  BYTE, 

SECSID  BYTE, 

MATCH  EYTE; 
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i  =  e; 

seosid  =  e; 

MATCH  =  false; 

/*  Search  down  the  sequencer  table  to  locate  the  */ 
/*  desired  sequencer  by  matching  the  names.  */ 

DO  WHILE  /*'  Haven't  found  the  sequencer  and  */ 

/*  haven't  exhausted  the  list.  */ 
(MATCH  =  FALSE)  ANL  (SECSlD  <  SECBENCERS); 

IF  /#  The  two  characters  match.  */ 

( CHAR ( I )  =  S EC  STABLE (SEO? IB) .SECiNAME (I ) )  THEN 

DO;  /#  Check  for  end  of  strings.  */ 

/ 

IF  /*  Reached  the  end  of  the  strings.  */ 

CHAR  (I )  =  '*'  TEEN 

/*  Have  located  the  desired  sequencer.  #/ 
MATCH  =  true; 

ELSE 

/*  look  at  the  next  character.  */ 
i  =  i  +  1; 

END;  /*  Check  for  end  of  strings.  */ 

SISS 


DO;  /*  Ready  for  check  of  next  entry.  */ 
i  =  z; 

SECSID  =  SEOtlD  ♦  1; 

END;  /*  Ready  for  check  of  next  entry.  */ 

END;  /<*  While  loop  search  for  desired  sequencer.  */ 

IF  /*  Have  found  the  sequencer. 

(MATCH  =  TRUE)  THEN 

/*  Return  its  index  in  the  SEQSTAELE.  */ 

RETURN  SEC sid; 

ELSE 
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/*  Return  NOT^FOUND  error  code.  */ 
RETURN  NOT* FOUND? 

end;  /*  TC*LOCATE*SEC  Procedure.  */ 


/*  TRAFFIC  CON TP.OIIER  INTERFACE  MODULES  */ 

/*  AWAIT  Procedure  */ 


/*- 

/* 

/* 

/* 

/* 

/* 

/* 

/* 


-*/ 

*/ 

V 

*/ 

*/ 

*/ 

*/ 

*/ 


Inter-process  synchronization  primitive. 
Suspends  execution  of  the  calling  process  until 
the  event  specified  in  the  input  argument 
'E7C$VAL$PAEM '  has  occurred  (the  eventcount 

that  the 

virtual  processor 


reaches  this  value).  The  result  is  that 


process  will  "give  away 
tc  which  it  is  bound. 


tne 


AWAIT :  PROCEDURE ( EVENTCOUNT ,  VALUE )  REENTRANT  PUBLIC? 


DECLARE  EVENTCOUNT  POINTER, 
vaiue  wo? r , 

E7C*ID  BYTE, 

CUR RENT*7?  BYTE, 
PROCESS  BYTE; 


/*  Assert  global  lock  on  the  Active  Process  Table.  */ 
DO  WHILE  LOCK SET (PAPT$LCCE  ,119  )  j 

end; 


/*  Get  identity  of  the  virtual  processor  running  on  */ 
/*  physical  processor.  */ 
CURRENT*VP  =  ITC  *RET$V?  ? 

/*  Search  the  Active  Process  Table  (by  the  load  List  */ 
/*  to  find  the  process  bound  to  the  running  virtual  5V 
/*  processor.  */ 
PROCESS  =  LOADALIST(CPUiNUMSER); 


DO  WHILE  /*  Haven't  found  the  process  bound  to  this  vp.  */ 
( APT ( PROCESS ) .VP* ID  <>  CURRENT *V?  )  J 


/*  Look  at  the  next  entry  in  the  Ioad*List.  */ 
PROCESS  =  APT (PROCESS ) .LOAD$TEREAD ? 


i 


ENE?  /*  While  loop  search  of  Load^List.  */ 

/*  Gpt  the  E7C$TA3LE  index  for  this  eventcount.  #/ 

EVC$ID  =  TC$LOCATE$EVC(EVENTCOUNT)  ; 

I?  /*  This  process  is  to  enter  the  blocked  state.  */ 
EVC$TAIIE(E7C$ID)  .EVC$VAIUE  <  VALUE  TEEN 

DO?  /*  Set  the  required  APT  values.  */ 

APT (PP.0CESS  ). STATE  =  PLCCEEE  ? 

APT ( PROCESS ) .  VP$ID  »  Nil; 

AFT (PH OC ESS ). E7C£ VALUE £AW  =  VALUE? 

/*  Add  blocked  orocess  to  head  of  blocked  list.  */ 
APT (PROCESS ) .THREAD  *  EVC STABLE ( E7C ? ID J. APTiFTH ? 

/*  Feset  table  pointer  to  the  current  process.  #/ 

evc  Stable  (evc?ie ) . apt$ptr  =  currentsyp; 

END;  /*  To.  Place  process  in  the  blocked  state.  */ 
ELSE 

/*  If  the  event  has  already  occurred,  process  will  */ 
/#  enter  the  ready  state  —  it  will  not  be  blocked.  */ 
APT(PHOCESS). STATE  =  READY? 

A?m (PROCESS ) . VP ?IE  «  NIL; 

CALL  TC^SCFEDULEF.; 


ADVANCE:  PROCEDURE(EVENTCOUNT)  REENTRANT  FuBLIC; 

DECLARE  EVENTCOUNT  POINTER, 

EVCilD  BYTE, 

PROCESS  BYTE, 

PREV  BYTE, 

FHP  BYTE, 

VP  BYTE, 

HI$FRI  BYTE, 

PS$TO$SEND  BYTE, 

PEiSENT  BYTE? 

DECLARE  PE?PHP ( 16 )  BYTE, 

PE$VP (4 )  BYTE; 

/*  Assert  global  lock  on  the  Active  Process  Table.  */ 

DO  WHILE  LOCKSET (0AFT$LOCK ,  119  )  J 
END? 

/*  Increment  the  value  of  the  eventcount  by  one.  */ 
EVC$TABIE(EVC$ID).m$mtJS  = 

EVC STABLE ( EVC  ^ID ) . E VC  A VALUE  +  1? 

/*  Search  Blocked  list  associated  with  the  eventcount  */ 

/#  and  unblock  those  processes  waitirg  for  this  */ 

/*  event.  Set  PROCESS  to  the  first  rr, ember  of  the  */ 

/*  Blocked  List.  */ 

PROCESS  =  EVCiTABLE(E7C >ID) .APTiFTRJ 
PPEV  =  pfocess; 

/*  Initialize  PEiPHF  array.  */ 

DO  PHP  =  0  TO  NRiFFFS; 

?E$PHF(FF?)  »  FALST ; 
end; 

DO  WHILE  /*  Not  end  of  Blocked  List.  */ 

process  o  nil; 

IF  /*  The  event  has  already  occured.  */ 
(EVC$TABLE<EVC$ID).£VC$VALUE  >= 

APT (PROCESS ). EVC $VAIU2$ AW)  THEN 

DO;  /*  Unblock  process  (set  state  to  ready!*  zero 
/*■  Eventcount  Value  Awaited  entry  of  APT  and 
/*  flag  the  physical  processor  for  preemption.  ’V 
APT(PROCESS). STATE  =  READY; 

apt(peocess).evc$valus$aw  *  z; 

FE$PF?(AFT (PROCESS ) .AFFINITY )  =  TRUE; 
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/*  Remove  process  from  the  31ockea  list.  */ 

IF  /*  First  member  of  the  Blocked  list.  #/ 

(PREV  =  Nil)  THEN 

/*  Reset  pointer  around  the  deleted  member.  */ 
EVC$TABLE(EVC$ID).AFT$FTR  = 

APT (PROCESS). thread; 

EISE 

/*  Set  previous  member's  pointer  around  the  */ 
/*  deleted  process.  <7 

APT (PRE7) .THREAD  =  APT(PROCESS ) .THREAD; 

END;  /#  Do.  Remove  process  from  Blocked  List.  #/ 

/*  SEARCH  NEXT  ENTRY  */ 

PREV  =  process; 

FROCESS  =  APT(PROCESS). THREAD; 

END;  /*  ii'hile  loop  search  of  Blocked  List.  */ 

DO  /*  Look  for  the  PHP's  with  TP's  to  oreempt.  */ 

PH?  -  0  to  pfps; 

IF  /*  FFF  is  flagged  for  a  preemot.  */ 

PE$?FP (PHP '  =  TRUE  THEN 

TO;  /#  Find  VP's  to  preempt.  */ 

TO  /*  Flag  all  VP's  for  preemption.  */ 

vp  ■  e  to  vps*?er$cpc; 
pf$v?( vp )  =  true; 

end;  /*  Initialize  PE$VP  array.  */ 

HiiPRi=  e; 

PE$TO$SEND  =  0; 

FROCESS  =  LOADUIST(FHP) ; 

DO  WHILE  /*  Search  down  Load  List  to  find  those  */ 
/*  processes  which  should  be  running.  */ 
/*  Determine  which  VFs  not  to  preempt.  */ 
(PROCESS  <>  NIL)  AND 
( HI$PRI  <  VPS  $FER$CFU ) ? 
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IF  /*  Found  a  process  which  should  te  running  */ 
/*  that  actually  is  running.  */ 

APT(PROCESS>. STATE  =  RUNNING  TFEN 

DO;  /<*  Increment  number  found  and  do  rot  */ 

/*  preempt  its  VP.  */ 

HliPRI  =  El $PRI  +  i; 

FEiV?(AFT(FROCESS) .VFilD)  =  FAISS; 

end; 


IF  /*  Found  a  process  which  should  te  running  */ 

/*  but  is  in  the  ready  state.  */ 

APT(PROCESS). STATE  =  READT  TEEN 

DO;  /*  Increment  number  found  and  indicate  */ 

/*  that  a  preempt  will  have  to  be  sent 
/*  to  get  it  running. 

ElAPRI  =  KI$FRI  ♦  i; 

PE$T0$SEND  =  PE$TO*SEND  +  1J 

end; 

END;  /*  While  loop  search  of  load  List.  #/ 

PEiSENT  *  0?  /#  Used  to  seep  track:  of  the  */ 

/*  number  of  preempts  sent.  */ 
VP  *  t ;  /*  Regin  at  first  VP  on  the  PEP.  */ 

DO  WEILS  /*  There  are  more  preempts  to  send.  */ 

(?E$SSNT  <*  PE$TO$SEND); 

I?  /*  A  preempt  is  to  be  sent  to  this  VP.  */ 
PE$VP(VF)  =  TRUE  TEEN 

DO;  /*  Issue  the  preempt  and  tally  it.  */ 

CALL  ITCiSFND$PRFEMPT(FFP,VP); 

PE$SENT  =  PE$SENT  *  1? 

END;  /#  Issue  preempt.  */ 

/*  Check  the  next  VP.  */ 

vp  *  vp  +  1; 
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END;  /*  While  loop  send  preempts.  */ 

END*  /*  While  loop  determine  VPs  to  preempt.  */ 

END*  /*  Determine  PHPs  to  preempt.  */ 

END* 

/*  Ready  the  calling  process.  #/ 

/*  Get  identity  of  running  VP.  */ 

VP  =  ITC$RET$ VP  > 

/*  Search  load  List  Thread  to  find  VP$ID  match.  * / 
PPOCESS  «  lOADiLlST(CPUiNUMBER); 

DO  WHILE  /*  Have  not  found  process  hound  to  this  VP.  */ 
(APT (PROCESS  )  .VP$ID  <>  VP),* 

/*  look  at  neit  entry  in  Load  List.  */ 

PROCESS  =  apt(process).load$teread; 

end;  /*  While  loop  search  of  Load  List.  */ 

/*  Ready  the  calling  process.  */ 

A?T( PROCESS) .STATE  -  READY; 

APT(FROCESS).VP$ID  =  NIL; 

CALL  TCiSCFEDULERJ 


/*  Unlock  Active  Process  Table.  */ 
AFTiLOCK  =  0,* 


return; 

end;  /*  ADVANCE  Procedure.  */ 


/#  TICKET  Procedure  */ 

/* - */ 

/*  Function  call.  Returns  a  unique  sequencer  value.  */ 

/a*!##**####  $««$#$  $$$£#«$  f 


TICKET:  PROCEDURE (SEQUENCER)  BYTE  REENTRANT  PUBLIC* 
DECLARE  SEQUENCER  POINTER, 

SEQAID  EYTE, 

vaiue  word; 
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/*  lock  the  Active  Process  Table.  */ 

DO  WHILE  IOCKSET((?APT$LOCK ,  119 )  J 

end; 

/*  Identify  the  sequencer. 

SEQ$ID  *  iOCATEiSEO(SECUENCER); 

/*  First  obtain  value  to  be  returned  to  the  caller  <*/ 
VALUE  =  SEQ$TABLE(SSQ$ID) .SEQ$VALUEJ 

/*  Then  increment  the  value  of  the  sequencer  */ 
SEC$TAJLE(SEOiID) .SEQ$ VALUE  = 

SE0$TA3LE(SEQ$ID ). SE0$ VALUE  *  1? 

/**  Unlock  the  Active  Frocess  Table  */ 

APT$L0CE  =  0; 

/*  Return  the  value  to  the  caller.  */ 

RETURN  VALUE? 

end;  /*  TICKET  Procedure.  */ 

/ft###########  «##### 


/* 

READ  Procedure 

*/ 
_ *  / 

/ 

/* 

/* 

Function  call.  Returns 
eventcount  specified  in 

the 

the 

current  value  of  the 
call . 

V/ 

*/ 

*/ 

READ:  PROCEDURE (EVENTCOUNT)  BITE  REENTRANT  PU3LIC ; 
DECLARE  EVENTCOUNT  POINTER, 

EVC$ID  BYTE, 

VALUE  word; 

/**  Lock  the  Active  Process  Table.  */ 

DO  WHILE  LOCKSET(OAPT$LOCE,119); 
end;  ‘ 

/*  Identify  the  eventcount.  */ 

EVCilD  =  LOCATE$EVC (EVENTCOUNT  )  J 

/*  "Read"  the  current  value  of  the  eventcount.  */ 
VALUE  *  EVC$TABLS(EVC$ID) .EVC$VALUEJ 

/*  Unlock  the  Active  Process  Table.  V 
A?T$L0CK  *  0; 

/*  Return  the  current  value  to  the  caller.  */ 
RETURN  VALUE? 
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SND»  /*  READ  Procedure.  */ 

/AA***A**A**AA*AAAAA***A*A#*AA AAAAAAAAAAAAAAAAAA* AAAAAA* AAA / 


/*  CREATE$EVC  Procedure  V 

/* - - - - - */ 

/*  "Creates'  an  eventcount  by  making  an  entry  for  it  */ 

/*  in  the  eventcount  table  "EVC4TA3LE"  and  setting  */ 

/*  the  initial  value  of  the  eventcount  to  C.  */ 


/$aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa / 

CREATEiEVC:  F ROC EDURF( EVENTCOUNT )  REENTRANT  FUFIICJ 
DECLARE  EVENTCOUNT  POINTFF, 

DECLARE  CHAR  BASED  NAPE  (6)  BITE; 

DECLARE  I  BITE? 

/*  Lock  tne  Active  Process  Table  */ 

DO  WHILE  LOCKS ET (GAPTiLOCK ,119) { 

end; 

IF  /*  The  eventcount  had  not  already  been  created  */ 
LOCATE$EVC (EVENTCOUNT)  *  NOTiFOUND  THEN 

DO? 

i  *  v; 

ro  /*  Copy  the  name  into  EVC$TABLE  */ 

WHILE  (CHAR ( I )  <>  '%')  AND  (I  <  5); 

/*  Copy  the  character  into  the  table.  */ 

EVC  $T ABLE (EVENTS ). EVC$ NAME ( I )  =  CHAR(I)! 

END?  /*  While  loop.  */ 

/*  Insert  the  delimiter  in  the  table  entry.  */ 

EVC  $T ABLE ( EVENTS ) . EVC$NAPE( I )  =  '%' i 

/+  Increment  EVENTS  to  indicate  a  new  addition.  */ 
EVENTS  =  EVENTS  ♦  i; 

END;  /*  Create  the  eventcount.  */ 

/*  Unlock  the  Active  Process  Table.  */ 

APT$LOCK  *  e; 

return; 

end;  /*  CREATE^EVC  Procedure.  */ 

/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa&aaaa / 
/#  CREATS4SEC  Procedure  v/ 
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/* - - - - - */ 

/+  "Creates"  a  sequencer  by  establishing  an  entry  in  */ 
/*  the  sequencer  table  “SEQ$TABLE"  and  sets  the  */ 
/*  initial  value  to  0.  */ 


/ft**#**#***##*#*#***********##*******#*************#*******/ 

CPEAT2$SEC:  PROCEDURE (SEQUENCER)  REENTRANT  PUBLIC? 

DECLARE  SEQUENCER  FOINTER; 

DECLARE  CFAF.  EASED  NAME  (6)  BYTE? 

DECLARE  I  BYTE; 

/*  Lock  the  Active  Process  Table  */ 

DO  WHILE  LOCESET(@APT$ LOCK, 113); 

end; 

IF  /*  The  sequencer  had  not  already  been  created  */ 
LOCATEiSSO(SEOUENCER)  *  NOT$FOUND  THEN 

do; 

i  «  o; 

DO  /*  Copy  the  name  into  SEQiTABIE  */ 

WHILE  (CHAR ( I )  <>  '%')  AND  (I  <  5>J 

/*  Copy  the  character  into  the  table.  V 
SECiTAELP(SEQUENCERS).SECiNA^E(I)  =  CPAR(I)} 

END;  /*  While  loop.  */ 

/*  Insert  the  delimiter  in  the  table  entry.  */ 

SEQ$T  ABIE  (SEQUENCERS)  .SS0$NAME(I }  = 

/*  Increment  SEQUENCERS  to  indicate  a  new  addition.  */ 
SEQUENCERS  «  SEQUENCERS  ♦  1J 

END;  /*  Create  the  sequencer.  */ 

/*  Unlock  the  Active  Process  Table.  */ 

APTUOCK  *  e; 

return; 

end;  /*  CPEATE$SEC  Procedure.  */ 

<«$#:Cc**>)t*«*#!SHiJ*##**s****$$*<t$******#**<i**##$***r*********iJe*«/ 


/*  CREATS$PR0CESS  Procedure  */ 

/# - - - - - */ 

/*  "Creates"  a  process  by  initializing  its  stack  and  */ 

/*  initializing  an  entry  for  it  in  the  Active  Process  */ 

/*  Table.  */ 
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CREATE$PROCESS:  PROCEDURE (PPB^FTR )  REENTRANT  PUBLIC? 
EECIARE  PPE$PTR  POINTER; 

DECLARE  INITiSTACKiFRAMS  STRUCTURE 


(FL 

WORD, 

CS 

WORD, 

IP 

WORD, 

ES 

WORD , 

DS 

WORD, 

AX 

WORD, 

cx 

WORD, 

DX 

WORD , 

BX 

WORD, 

SI 

WORD, 

DI 

WORD , 

RET 

WORD, 

BP 

WORD, 

SP 

WORD) ; 

DECLARE  INTERRUPT  LITERALLY  '119'; 

/*  Lock  the  Active  Process  Table.  */ 

DO  WHILE  LOCK SET (QAPTiLOCK ,119 )  J 

end; 

/*  Set  up  Initialization  stack  frame.  */ 
INIT$STACX$FRAM2.FL  =  PRO$PARAM.FLj 
I NIT$ STAC K$ FRAME. CS  =  PRO$PARAM . CS  ? 

I NITiSTAC ENFRAME.  IP  *  PRO$?ARAM.  IP ! 
INIT$STACE$FRAME.F?  =  PROiPARAK.ES; 
INIT$STACK$FRAME.DS  =  PRO$PARAM ,DS J 
INITiSTACKiFRAME.AX  *  FRO^PARAM .AX ? 
INIT$STACK$FRAME.CX  *  PROSPAEAM.CXJ 
INIT$STACK$FRAME.DX  *  PRO$PARAM.DX? 
INIT*STACE4FRAME.BX  *  PROiPARAM.RX? 
INIT$STACK$FRAME.SI  -  PROSPARAM .S I J 
INIT$STACE$FRAM2.DI  -  PRO$PARAM .DI J 
INIT*STACX$FRAME.RET  *  INTERRUPT 5 
INlT$STACK$FRAME.BP  *  e? 

INIT$STACE$FP.AME.SP  *  6? 

/*  Move  Initialization  stack  frame  into  memory.  */ 
M0VB(flINIT$STACK$FFAME,PPB.DBR,2S); 

/**  Enter  process  in  Active  Process  Table.  */ 
APT(PROCESSES ). STATE  *  PPR. STATE; 

APT(PROCESSES ) .AFFINITY  *  *PB. AFFINITY; 
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APT (PROCESSES ) .VP$IT  =  Nil; 

APT(PROCESSES ) .PRIORITY  =  PPB.FRIORITY; 

APT ( PROCESSES ) . EVC$VALUE$AW  =  0? 

APT ( PROC ES SES ) .THREAD  =  NIL? 

AFT (PROCESSES ) .DBR  =  PFB.DBR? 

/*  Enter  process  in  the  Loaded.  List  by  priority  */ 
PREV  =  nil; 

NEXT  »  L0AD$LIST (CFU$NUMBER)  J 

DO  WHILE  PPB. PRIORITY  >  APT ( NEXT ) .PR  I OR  ITT? 

PREV  =  next; 

next  =  aft(next).load$tkreab; 
end; 

IF  NEXT  =  NIL  THEN 

APT  (PREV  )  .LOAE-ATEREAD  =  ENTRY; 

ELSE 

IF  NEXT  =  LOAD $L I ST (CPU* NUMBER  )  TEEN 

do; 

APT(ENTRY)  .LOAD$THREAD  = 

LOAD $L 1ST (CPU A NUMBER) J 
LOAD $L I ST ( CPU £ NUMBER  )  =  ENTRY; 

ELSE 

do; 

APT (PREV) .LO AD $ THREAD  *  ENTRY? 
AFT(ENTRT).LOAD$THREAr  =  NEXT; 

end; 


/*  Unlock  the  Active  Process  Table.  */ 
AFTUOCK  =  ?,* 

return; 

end;  /*  CPEATE$PROC?SS  Procedure.  */ 


/* 

/*. 

/♦ 

/* 

/* 

/* 

/* 

/* 


TC$PF$FANDLER  Procedure 


*/ 
•*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 


Handles  preempt  interrupts.  Called  by  the 
Traffic  Controller  in  response  to  a  virtual 
preempt  interrupt.  This  module  serves  as  the 
virtual  interrupt  entry  point  into  the  Traffic 
Controller. 

=>  Constitutes  a  loop.  <= 


TC$?E$HANDLER:  PROCEDURE  REENTRANT  PUBLIC? 

/*  Lock  the  Active  Process  Table.  */ 

DO  WHILE  LOCESET ((?A?T$LOCK ,119 ) ; 
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end; 


CALL  TCiSCFErUIEE » 

/*  Unlock  the  Active  Process  Table.  */ 

AFTiiocE  =  e; 

return; 

END;  /*  TC  $PEAEANDLEP.  Procedure.  */ 
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